[llvm-dev] O2 Aggressive Optimization by Clang

[mats petersson via llvm-dev]

On 20 July 2018 at 13:21, Umesh Kalappa via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Edited the Subject.
>
> On Fri, Jul 20, 2018 at 5:50 PM, Umesh Kalappa <umesh.kalappa0 at gmail.com>
> wrote:
> > 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 .
>

What are you actually trying to achieve? The sample code does not actually
DO anything useful, even if it's technically possible to find ways to
observe the value of `i` and `j` outside of `main`.
What do you expect the compiler to do with this?

If nothing else is using `i` and `j`, what's the purpose of changing their
value?

If you ARE using those values elsewhere, the using `volatile` is indeed the
right thing to do. Or calling some functions inside `main`, that will cause
the compiler to understand that "this does something more than just update
some variables".

--
Mats

>
> >
> > Thank you in advance.
> > ~Umesh
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180720/bf2c102a/attachment.html>