[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a2e658a936a4b7788b23c57ff37119b@AcuMS.aculab.com>
Date: Sat, 10 Apr 2021 12:44:55 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'David Malcolm' <dmalcolm@...hat.com>,
Peter Zijlstra <peterz@...radead.org>
CC: Ard Biesheuvel <ardb@...nel.org>,
"linux-toolchains@...r.kernel.org" <linux-toolchains@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"Jason Baron" <jbaron@...mai.com>,
"Steven Rostedt (VMware)" <rostedt@...dmis.org>
Subject: RE: static_branch/jump_label vs branch merging
From: David Malcolm
> Sent: 09 April 2021 14:49
...
> With the caveat that my knowledge of GCC's middle-end is mostly about
> implementing warnings, rather than optimization, I did some
> experimentation, with gcc trunk on x86_64 FWIW.
>
> Given:
>
> int __attribute__((pure)) foo(void);
>
> int t(void)
> {
> int a;
= 0;
> if (foo())
> a++;
> if (foo())
> a++;
> if (foo())
> a++;
> return a;
> }
>
> At -O1 and above this is optimized to a single call to foo, returning 0
> or 3 accordingly.
Interesting horrid idea.
The code generated for the above should be:
call foo
jz label
So objtool could find the relocation entries for 'foo'
and use that information to replace the call instruction
(and maybe the jz) with a suitable alternate instruction
sequence.
Although that might end up with a game of 'whack-a-mole'
on the perverse instruction sequences the compiler
generates.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists