<div dir="ltr"><div>Agree, and I did : )<br></div>Please refer to this mailing list: <a href="https://gcc.gnu.org/ml/gcc/2016-03/msg00179.html">https://gcc.gnu.org/ml/gcc/2016-03/msg00179.html</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 19, 2016 at 1:25 AM, Daniel Berlin <span dir="ltr"><<a href="mailto:dberlin@dberlin.org" target="_blank">dberlin@dberlin.org</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">I suspect you should just go ask #1 on the gcc mailing list and see what the answer is.<div>We are basically trying to figure out their reasoning, but we should instead just go ask what it is :)</div><div><div class="h5"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 18, 2016 at 8:33 AM, Chuang-Yu Cheng 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><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><br>  c->f1_ = 0;<br>  c->f2_ = 0.f;<br>}<br><br></span></div>Any opinions please let us know.<br></div>Thanks!<span><font color="#888888"><br></font></span></div><span><font color="#888888"><br>CY</font></span></div><div><div><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><br>_______________________________________________<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>
<br></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br></div>