Re: common subexpression elimination no longer working for asm()?

["Jan Beulich" <JBeulich at suse dot com>]

>>> On 23.10.14 at 13:32, <richard.guenther@gmail.com> wrote:
> On Wed, Oct 22, 2014 at 5:28 PM, Jan Beulich <JBeulich@suse.com> wrote:
>> I noticed the issue with 4.9.1 (in that x86 Linux'es
>> this_cpu_read_stable() no longer does what the comment preceding
>> its definition promises), and the example below demonstrates this in
>> a simplified (but contrived) way. I just now verified that trunk has
>> the same issue; 4.8.3 still folds redundant ones as expected. Is this
>> known, or possibly even intended (in which case I'd be curious as to
>> what the reasons are, and how the functionality Linux wants can be
>> gained back)?
> 
> For 4.8 the CSE happened at the RTL level.  On the GIMPLE level
> we inline too early to CSE based on the fact the functions are pure.

Inlining doesn't really matter here according to my tests: Two
side by side identical asm()s without other side effects don't get
folded either.

In any event - is there anything that can be done about this?

> Note that dummy() may change m and p, so what 4.8 did was bogus:
> 
> #APP
> # 7 "t.c" 1
>         nop m(%rip)
> # 0 "" 2
> #NO_APP
>         movl    %edi, %esi
> #APP
> # 14 "t.c" 1
>         nop p
> # 0 "" 2
> #NO_APP
>         call    dummy
>         movl    %ebx, %esi
>         movl    %ebx, %edi
>         call    dummy

It wasn't bogus at all - by telling the compiler that the input to the
respective asm() is just the address of an object, the programmer
takes the responsibility that the pointed to object is not going to
change (or it changing doesn't matter). It's the whole purpose of
the use of the similar construct in Linux to allow the compiler to
eliminate multiple instances _across_ function calls.

Jan