<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 8:33 AM, Chuang-Yu Cheng <span dir="ltr"><<a href="mailto:cycheng@multicorewareinc.com" target="_blank">cycheng@multicorewareinc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>1. Same question as David, why &c - 8 is invalid? Is it related to below statements In C99 standard?<br><br><a href="http://6.5.3.3" target="_blank">6.5.3.3</a>:<br>"Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an<br>address inappropriately aligned for the type of object pointed to, and the address of an object after the<br>end of its lifetime."<br><br></div>2.
 We are trying to preserve 1st load and remove other loads now, because 
our test pattern can not get rid of "-fno-strict-aliasing", and 
additional loads hurt performance. We did some change in 
SROA::runOnAlloca, we try to do something like this:<br><br>void qux(PB* _c) {<br>  PB* c;         <= insert this for original code<br>  bar(&_c);<br><br>  c = _c;        <= insert this for original code<span class=""><br>  c->f1_ = 0;<br>  c->f2_ = 0.f;<br>}<br></span></div></div></div></div></blockquote><div><br></div><div>Not sure I quite understand the question - if we believe GCC's interpretation to be incorrect/Clang's to be correct, there's nothing our optimizers can do to correct the code & free us up to do the optimization GCC does here.<br><br>If you're talking about modifying your code to allow Clang to optimize it better - yes, it seems like if you copy the pointer:<br><br>void qux(PB* _c) {<br>  bar(&_c);<br>  PB *c;<br>  c->f1_ = 0;<br>  c->f2_ = 0.f;<br>}<br><br>Should do the right optimization, because there's no way that 'bar' could give _c an address that would alias 'c' in any way.<br><br>I'm not sure what you're referring to when you mention making changes to SROA.<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><span class=""><br></span></div>Any opinions please let us know.<br></div>Thanks!<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><br>CY</font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 11:24 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Why would computing that pointer be invalid?<br><br>(I could imagine, if there was no object behind c to point to it would be invalid - but that's a dynamic property of the program that the compiler, given this code, can't prove /isn't true/ (the programmer might've constructed the caller such that it does always have an object behind 'c' to point to))</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Fri, Mar 18, 2016 at 1:28 AM, Markus Trippelsdorf via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><div>On 2016.03.17 at 16:35 -0700, Chris Lattner via llvm-dev wrote:<br>
><br>
> > On Mar 15, 2016, at 7:58 AM, Chuang-Yu Cheng via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Please look at this c code:<br>
> ><br>
> > typedef struct _PB {<br>
> >   void* data;  /* required.*/<br>
> >   int   f1_;<br>
> >   float f2_;<br>
> > } PB;<br>
> ><br>
> > PB** bar(PB** t);<br>
> ><br>
> > void qux(PB* c) {<br>
> >   bar(&c);              /* c is escaped because of bar */<br>
> >   c->f1_ = 0;<br>
> >   c->f2_ = 0.f;<br>
> > }<br>
> ><br>
> > // gcc-5.2.1 with -fno-strict-aliasing -O2 on x86<br>
> > call    bar<br>
> > movq    8(%rsp), %rax<br>
> > movl    $0, 8(%rax)<br>
> > movl    $0x00000000, 12(%rax)<br>
> ><br>
> > // llvm 3.9.0 with -fno-strict-aliasing -O2 on x86<br>
> > callq    bar<br>
> > movq    (%rsp), %rax<br>
> > movl    $0, 8(%rax)<br>
> > movq    (%rsp), %rax<br>
> > movl    $0, 12(%rax)<br>
> ><br>
> > You can see that llvm load "c" twice, but gcc only load "c" once.<br>
> > Of course, in bar function, you may do something very dangerous, e.g.<br>
> ><br>
> > PB** bar(PB** t) {<br>
> >    *t = (PB*) t;<br>
> > }<br>
> ><br>
> > But gcc doesn't care bar's definition.<br>
> > Is llvm too conservative, or gcc too aggressive in this pattern?<br>
><br>
> In my opinion, in the face of -fno-strict-aliasing, GCC is being too<br>
> aggressive.  It would be interesting to hear what they think.<br>
<br>
</div></div>We discussed this issue briefly on the #gcc IRC channel.<br>
Richard Biener pointed out that bar cannot make c point to &c - 8,<br>
because computing that pointer would be invalid. So c->f1_ cannot<br>
clobber c itself.<br>
<span><font color="#888888"><br>
--<br>
Markus<br>
</font></span></div></div><div><div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>