llvm dev - Jul 2018 - O2 Aggressive Optimization by GCC

Hi All ,

We are looking at the C sample i.e

extern int i,j;

int test()
{
while(1)
{       i++;
        j=20;
}
return 0;
}

command used :(clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
)
clang -S test.c -O2

the generated asm for x86

.L2:
        jmp     .L2

we understand that,the infinite loop is not  deterministic ,compiler
is free to treat as that as UB and do aggressive optimization ,but we
need keep the side effects like j=20 untouched by optimization .

Please note that using the volatile qualifier for i and j  or empty
asm("") in the while loop,will stop the optimizer ,but we don't
want
do  that.

Anyone from the community ,please share their insights why above
transformation is right ?

and without using volatile or memory barrier ,how we can stop the
above transformation .


Thank you in advance.
~Umesh

On Fri, 20 Jul 2018 at 13:20, Umesh Kalappa via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Anyone from the community ,please share their insights why above
> transformation is right ?
In addition to the UB you mentioned yourself, there's no way any other
thread could detect that j has been modified without introducing a
race (because this thread doesn't do any synchronization and j is
non-atomic).

I sort of doubt that the optimizer is making use of that fact because
it's very hard in general to prove that no synchronization occurs
elsewhere. But it should probably give you pause over just what you're
trying to do.
> and without using volatile or memory barrier ,how we can stop the
> above transformation.
You could use a (possibly memory_order_relaxed) atomic operation to
store to j. That would then be something the compiler has to ensure
reaches other threads.

Cheers.

Tim.

Hi Tim ,

Thank you for the suggestions,we need the side effects(assignment and
increment) of the test() take place and observable for  other threads
,without using the memory model construct .

Otherway,how we can say optimization not to consider the UB and
optimization way the statements,any clang options for the same ?

Thank you
~Umesh

On Fri, Jul 20, 2018 at 6:18 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> On Fri, 20 Jul 2018 at 13:20, Umesh Kalappa via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Anyone from the community ,please share their insights why above
>> transformation is right ?
>
> In addition to the UB you mentioned yourself, there's no way any other
> thread could detect that j has been modified without introducing a
> race (because this thread doesn't do any synchronization and j is
> non-atomic).
>
> I sort of doubt that the optimizer is making use of that fact because
> it's very hard in general to prove that no synchronization occurs
> elsewhere. But it should probably give you pause over just what you're
> trying to do.
>
>> and without using volatile or memory barrier ,how we can stop the
>> above transformation.
>
> You could use a (possibly memory_order_relaxed) atomic operation to
> store to j. That would then be something the compiler has to ensure
> reaches other threads.
>
> Cheers.
>
> Tim.