Yes, I misread, because I didn't think -O1 turned on strict aliasing and missed that part<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 25, 2016, 8:23 PM Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Nov 25, 2016, at 4:17 PM, Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-4505962083511215327Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><br class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Nov 25, 2016 at 6:10 AM, Hubert Tong <span dir="ltr" class="gmail_msg"><<a href="mailto:hubert.reinterpretcast@gmail.com" class="gmail_msg" target="_blank">hubert.reinterpretcast@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg">On Fri, Nov 25, 2016 at 1:42 AM, Daniel Berlin <span dir="ltr" class="gmail_msg"><<a href="mailto:dberlin@dberlin.org" class="gmail_msg" target="_blank">dberlin@dberlin.org</a>></span> wrote:<br class="gmail_msg"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">What is the purpose of the union there?<br class="gmail_msg"></div></blockquote></span><div class="gmail_msg">The
purpose of the union is to increase portability by ensuring that the
placement new is not being performed on insufficiently sized or aligned
memory.<br class="gmail_msg"></div></div></div></div></blockquote><div class="gmail_msg">Gotcha</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><span class="gmail_msg"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">I ask because pretty much no compiler will respecting the unioning without visible accesses in all cases, because it would ruin most optimization[1]<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">But i'm also not sure it's required in this testcase to make your testcase fail.</div></div></blockquote></span><div class="gmail_msg">It isn't. The program should be valid, without the union, on platforms where <span style="font-family:monospace,monospace" class="gmail_msg">int</span> and <span style="font-family:monospace,monospace" class="gmail_msg">float</span> have the same size an alignment.<br class="gmail_msg"></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Right, so you need to debug that first, and see what's going wrong.</div><div class="gmail_msg">Without TBAA info in the .ll file, this should just work.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"></div><span class="gmail_msg"><div class="gmail_msg"> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In practice, handling placement new properly in gcc required the equivalent of a new intrinsic (in gcc, it required adding CHANGE_DYNAMIC_TYPE_EXPR).</div></div></blockquote></span><div class="gmail_msg">Sure; my question is whether or not there is already a solution in the works for LLVM. If not, then I'll try to work with some folks to propose an intrinsic.</div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I would first focus on understanding why the testcase fails without any TBAA info at all.</div><div class="gmail_msg">In that case, i would expect it to work.</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div><br class="gmail_msg"></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">The PR says "passes with -fno-strict-aliasing”, my understanding is that it is failing only with the TBAA indeed.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">You don’t need the main and the union to reproduce, extracting foo() alone in its single own file is enough:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg">void *operator new(decltype(sizeof 0), void *) noexcept;</div><div class="gmail_msg">float *qq;</div><div class="gmail_msg">void foo(int *p, int *q, long unk) {</div><div class="gmail_msg"> for (long i = 0; i < unk; ++i) {</div><div class="gmail_msg"> ++*p;</div><div class="gmail_msg"> qq = new (static_cast<void *>(&q[i])) float(42);</div><div class="gmail_msg"> }</div><div class="gmail_msg">}</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">LICM will get the store to p out of the loop, conceptually turning it into:</div><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">void foo(int *p, int *q, long unk) {</div><div class="gmail_msg"> for (long i = 0; i < unk; ++i) {</div><div class="gmail_msg"> qq = new (static_cast<void *>(&q[i])) float(42);</div><div class="gmail_msg"> }</div><div class="gmail_msg"> ++*p;</div><div class="gmail_msg">}</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Now I don’t know if the use of placement new in this example is legal in the first place. I thought calling delete before using placement new was mandatory.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">CC Sanjoy, since he looked into TBAA recently and it reminds me a similar test case he mentioned, not with placement new but with a call to a function taking int * and float *, and passing the same address (call site was union).</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">— </div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Mehdi</div><div class="gmail_msg"><br class="gmail_msg"></div></div></blockquote></div>