<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">David,<div class=""> I’m not asking for the logic behind optimizing UB,</div><div class="">I’m asking for real world examples, a SPEC benchmark would do,</div><div class="">where optimizing UB actually proves to be beneficial.</div><div class=""><br class=""></div><div class="">I believe that in the real world it doesn’t happen, and I disagree</div><div class="">with the generalization of “constant-propagation after inlining is</div><div class="">beneficial” to “UB-propagation after inlining is beneficial”.</div><div class=""><br class=""></div><div class="">rather I believe that undef-propagation is the root cause of our problems.</div><div class=""><br class=""></div><div class="">But even if you disagree with my logic, we still don’t have any real world</div><div class="">examples showing the benefit of “UB-propagation after inlining".</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Peter Lawrence.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 19, 2017, at 8:25 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Jun 19, 2017 at 7:36 AM Peter Lawrence via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Sanjoy,<br class=""> <span class="Apple-converted-space"> </span>You have changed the subject. We still need real world examples<br class="">showing how taking advantage of “undef” results in beneficial optimization.<br class=""><br class="">My belief is that they don’t exist, my reasoning is this: real world programmers<br class="">are likely to run UBSan before compiling (or if they don’t they should), therefore<br class="">it is highly unlikely that any “undef” will actually exist during compilation of their<br class="">source code.<br class=""></blockquote><div class=""><br class="">Wait - that ^ doesn't seem to follow. The point of undefined behavior optimizations isn't to only break programs that would trigger UBSan. The point is to optimize on the assumption that they won't break UBSan/exhibit undefined behavior.<br class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">Yes, “Undef” can be created during SSA construction, but we already discussed<br class="">That in a previous email (its a register allocation problem).<br class=""><br class=""><br class="">The only other way I can see of “undef” occurring in IR is if we go out of our<br class="">way to optimize for example<br class=""><br class=""> <span class="Apple-converted-space"> </span>if ( ((i64)X + (i64)Y)) < INT_MIN || ((i64)X) + (i64)Y) > INT_MAX ) {<br class=""> <span class="Apple-converted-space"> </span>. . .<br class=""> <span class="Apple-converted-space"> </span>Z = X "+nsw” Y;<br class=""> <span class="Apple-converted-space"> </span>. . .<br class=""> <span class="Apple-converted-space"> </span>}<br class=""><br class="">Here “Z” could in theory be replaced with “undef”, but there is no point in doing so.<br class=""><br class="">Similarly with provably out-of-bounds GEP, similarly with provably invalid pointers,<br class="">etc, but again there is no point in doing so.<br class=""></blockquote><div class=""><br class=""></div><div class="">Why isn't there any point in doing so? One common situation where exploiting UB (aka: "assuming UB can't happen") may be beneficial is when the code in isolation is fine, but when inlined it's possible to prove certain paths create contradictions. That way even if the conditions for those paths can't be analyzed to prove they are unreachable (or values are not needed, etc), the compiler can skip all that and just collapse the code (remove the unreachable code, delete the value computation, etc) anyway.</div><div class=""> </div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><br class=""><br class="">So is there any other way of having “undef” appear in the IR ?<br class=""><br class=""><br class="">Peter Lawrence.<br class=""><br class=""><br class=""><br class="">> On Jun 16, 2017, at 7:45 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank" class="">sanjoy@playingwithpointers.com</a>> wrote:<br class="">><br class="">> Hi Peter,<br class="">><br class="">> Why we need an undef value is covered here:<br class="">><span class="Apple-converted-space"> </span><a href="http://sunfishcode.github.io/blog/2014/07/14/undef-introduction.html" rel="noreferrer" target="_blank" class="">http://sunfishcode.github.io/blog/2014/07/14/undef-introduction.html</a><br class="">> (in short, to do SSA construction well).<br class="">><br class="">> For a while we did not have a literal representation for poison.<br class="">> However, in practice having both undef and poison was problematic (see<br class="">> the paper), so we decided to ditch undef and keep poison.<br class="">><br class="">> However for the new poison to provide the same functionality as the<br class="">> old undef (which is now going away), we need a literal representation<br class="">> for the new poison.<br class="">><br class="">> -- Sanjoy<br class="">><br class="">> On Fri, Jun 16, 2017 at 3:03 PM, Peter Lawrence via llvm-dev<br class="">> <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">>> All,<br class="">>> These discussions seem to be based on the premise that there is a<br class="">>> need for the compiler to exploit undefined behavior for performance<br class="">>> optimization reasons.<br class="">>><br class="">>> So far the only beneficial optimization I am aware of that relies on some<br class="">>> form of “undefined” is Dan Gohman’s original project for LP64 targets of<br class="">>> promoting i32 induction variables to i64 and hoisting sign-extension out<br class="">>> of the loop.<br class="">>><br class="">>> But “undef” / “poison” never appears in either the original or the transformed<br class="">>> IR for these types of loops, instead properties of “+nsw” are used to<br class="">>> justify the transformation. The transformation does not just fall out because<br class="">>> we’ve done a good job at defining “undef” / “poison” IR nodes.<br class="">>><br class="">>> So I’d like to see some concrete examples of where the compiler can<br class="">>> do useful optimization based on “undef” / “poison” appearing explicitly<br class="">>> In the IR, finding some would surely advance this discussion.<br class="">>><br class="">>><br class="">>><br class="">>> Peter Lawrence.<br class="">>><br class="">>><br class="">>> _______________________________________________<br class="">>> LLVM Developers mailing list<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">>><span class="Apple-converted-space"> </span><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class=""><br class="">_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class=""><a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>