<div dir="ltr"><div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jun 28, 2017 10:32 PM, "Peter Lawrence" <<a href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>> wrote:<br type="attribution"><blockquote class="gmail-m_-7908215868555537875quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Sean,<div>         Many thanks for taking the time to respond. I didn’t make</div><div>myself clear, I will try to be brief...</div><div><br><div><div class="gmail-m_-7908215868555537875quoted-text"><blockquote type="cite"><div>On Jun 28, 2017, at 7:48 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>> wrote:</div><br class="gmail-m_-7908215868555537875m_1007539307351591597Apple-interchange-newline"><div><br class="gmail-m_-7908215868555537875m_1007539307351591597Apple-interchange-newline"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">On Wed, Jun 28, 2017 at 3:33 PM, Peter Lawrence via llvm-dev<span class="gmail-m_-7908215868555537875m_1007539307351591597Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.<wbr>org</a>></span><span class="gmail-m_-7908215868555537875m_1007539307351591597Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Chandler,<div>               where we disagree is in whether the current project is moving the issue</div><div>forward.  It is not.  It is making the compiler more complex for no additional value.</div><div><br></div><div>The current project is not based in evidence, I have asked for any SPEC benchmark</div><div>that shows performance gain by the compiler taking advantage of “undefined behavior”</div><div>and no one can show that.</div></div></blockquote><div><br></div><div>One easy way to measure this is to enable -fwrapv/-ftrapv on the compiler command line, which impede the compiler's usual exploitation of signed wrap UB in C. Last I heard, those options lead to substantial performance regressions.</div><div><br></div></div></div></blockquote><div><br></div></div><div>In my other emails I point out that Dan achieved the goal of hoisting sign-extension</div><div>out of loops for LP64 targets by exploiting “+nsw”,  and that this appears to be</div><div>the only example of a performance benefit.  I am not suggesting we remove this</div><div>optimization, and my emails point out that keeping this opt does not require that the</div><div>compiler model “undefined behavior”.</div><div><br></div><div><br></div><div>Heres what gcc says about those options</div><div><dt style="font-family:-webkit-standard"><code>-ftrapv</code></dt><dd style="font-family:-webkit-standard"><a name="m_-7908215868555537875_m_1007539307351591597_index-ftrapv-2350"></a>This option generates traps for signed overflow on addition, subtraction, multiplication operations. <br></dd><dt style="font-family:-webkit-standard"><code>-fwrapv</code></dt><dd style="font-family:-webkit-standard"><a name="m_-7908215868555537875_m_1007539307351591597_index-fwrapv-2351"></a>This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others. This option is enabled by default for the Java front end, as required by the Java language specification. </dd><div><br></div></div><div>Sounds like -fwrapv has equivocal results, at least for gcc, </div><div>my guess is that the same applies to llvm,</div><div><br></div><div>If anyone can show that -fwrapv makes a significant drop in SPEC-INT performance on</div><div>a plain old 32-bit machine then we need to look into it because it is kind of hard to believe</div><div>and doesn’t sound consistent with gcc.</div><div><br></div><div>I would do the tests myself, but all I have is my Mac-mini which is an LP64 machine,</div><div>(and no license for SPEC sources)</div><div></div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div>Is it possible to compile 32-bit programs on Mac? I know that on Linux you can typically install 32-bit libraries and run 32-bit programs. This is a bit extreme, but if that option isn't available on Mac, you could dual-boot Linux on your machine (at least temporarily) to perform the measurements. If that isn't possible, you might consider spinning up a Linux machine in the cloud (Amazon, Google Cloud, etc.) and doing the measurements there. Cloud machines aren't the most stable for benchmarking, but with a decent number of runs and appropriate data analysis you should be able to get reliable results.</div><div dir="auto"><br></div><div>Not having access to SPEC isn't an insurmountable hurtle either.</div><div>LLVM's test-suite has a number of interesting benchmarks and is freely available and easy to set up: <a href="http://llvm.org/docs/TestSuiteMakefileGuide.html">http://llvm.org/docs/TestSuiteMakefileGuide.html</a></div><div>If you ever acquire access to the SPEC sources, they are easy to drop in later if you need to.</div><div><br></div><div>-- Sean Silva</div><div><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-7908215868555537875quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div><div>On an LP64 machine we would need a flag to disable all but Dan’s optimization to</div><div>to do a comparison.  It would take some time, but it is doable.</div><div><br></div><div>Well, I guess that wasn’t brief, sorry!</div><font color="#888888"><div><br></div><div>Peter Lawrence.</div></font><div class="gmail-m_-7908215868555537875elided-text"><div><br></div><div><br></div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div>It sounds like you are implicitly claiming that there would be no performance regression. If the -fwrapv/-ftrapv measurements are in line with this, that will be useful new information for the discussion. But I think that you need to do the work here (and it isn't that much work compared to writing out emails; or perhaps I'm just a slow email writer).</div></div><div><br></div><div>I don't think anybody has really up to date numbers on the performance effect of those options on SPEC. Could you please get some up to date numbers before continuing this discussion? If the results are as you seem to imply, then that will be very convincing support for your point.</div><div><br>If you can't be bothered to do that, I have to question how invested you are in pushing the LLVM project toward a better solution to its current woes with the poison/undef situation.</div><div><br></div><div>-- Sean Silva</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>The current project doesn’t even address some of the bugs described in the paper,</div><div>in particular those derived from the incorrect definition of “undef” in the LangRef.</div><div><br></div><div>The current project perpetuates the myth that “poison” is somehow required.</div><div>It isn’t, and when I show proof of that you reply with “its in bug reports, etc”,</div><div>that’s BS and you know it, this hasn’t been explored.  The same thing happened</div><div>before when I said “nsw” shouldn’t be hoisted, folks replied with “that’s already</div><div>been studied and rejected”, but I did the research and found out no, it had not</div><div>been fully explored, Dan discarded the idea based on incorrect analysis and people</div><div>never questioned it. Dan created “poison” on a whim, and people picked up on it too</div><div>without question. We’ve been stuck with this self-inflicted wound ever since, and it is</div><div>time to heal it.</div><div><br></div><div>The entire situation here can be summarized as incorrect analysis, and failure to</div><div>fully root-cause problems, because people didn’t question their assumptions.</div><div>And we should not be surprised, it is one of the most common problems in software </div><div>engineering.  Haven’t you ever gone in to fix a bug only to find that what you are doing</div><div>is correcting someone else’s bug fix that didn’t actually fix anything because the person</div><div>doing the fix didn’t fully understand the problem?  Happens to me all the time.</div><div><br></div><div>The correct software engineering decision here is to fix the definition of “undef”,</div><div>delete “poison”, and not hoist “nsw” attributes.  That is a no-brainer.  There is nothing</div><div>to try out, or test, ormeasure. That is simply the way it has to be to avoid the current </div><div>set of problems.</div><div><br></div><div>I cannot emphasize that last point enough, fixing the definition of “undef”, deleting</div><div>“poison”, and not allowing “nsw” attributes to be hoisted, fixes all known problems,</div><div>even including ones that weren’t thought of before these discussions started, and</div><div>I don’t think there is any technical disagreement here, not even from John, Sanjoy,</div><div>or Nuno.  This is a no-brainer.</div><div><br></div><div>John and I do not have a technical disagreement,  John is having an emotional</div><div>reaction to the fact that he doesn’t have an answer to the function-inlining question.</div><div>We can’t disagree until he actually has an opinion to disagree with, but he is not</div><div>willing to express one.</div><div><br></div><div>The work on “poison” and “freeze” should be in new analysis and transform passes</div><div>in which folks can do whatever they want to propagate “undefined behavior” around</div><div>in a function (but “undefined behavior" should be an analysis attribute not an IR</div><div>instruction). Then folks can try to see if they can actually measure a performance gain</div><div>on any SPEC benchmarks. I think we all know this is going to turn out negative, but that’s</div><div>besides the point, the point is that “poison” and “freeze” are an experiment and need </div><div>to be treated as such and not just simply forced into the trunk because someone likes it.</div><div><br></div><div>What you are saying about ’the llvm way" goes against everything we know about</div><div>"software engineering”, that things have to be evidence based, have utility, and</div><div>be the least complex solution to avoid confusion.  And we do engineering reviews</div><div>and take review feedback seriously.  I suggest you take a step back and think about</div><div>that, because it sure seems to me like you’re advocating that we don’t do reviews and</div><div>we don’t base decisions on evidence.</div><span class="gmail-m_-7908215868555537875m_1007539307351591597gmail-HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Peter Lawrence.</div></font></span><div><div class="gmail-m_-7908215868555537875m_1007539307351591597gmail-h5"><div><br></div><div> <br><div><blockquote type="cite"><div>On Jun 28, 2017, at 12:16 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>> wrote:</div><br class="gmail-m_-7908215868555537875m_1007539307351591597gmail-m_-3468888268327129409Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_quote"><div dir="ltr">On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <<a href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures"><br></span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">Part I.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">The original LangRef appeared to be “nice and pretty”</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">and originally ‘undef’ did not seem to stick out.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">Then  evidence came to light in the form of bug reports, and</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">in the form of Dan Gohman’s email “the nsw story”, that all</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">was not good for ‘undef’ [1,2].</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">A proposal was made based on that evidence.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">A presentation was made at an llvm gathering.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">A paper was written. The proposal has even been</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">implemented and tested.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">The IR might not be so “nice and pretty” anymore,</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">but at least all the known bugs could be closed.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">I think everyone agreed that the case could be closed</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">based on the evidence at hand.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">However new evidence has come to light,</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">the function-inlining example for one,</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">which the proposal does not address.</span></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255);min-height:16px"><span style="font-variant-ligatures:no-common-ligatures"></span><br></div><div style="margin:0px;font-size:14px;line-height:normal;font-family:Menlo;background-color:rgb(255,255,255)"><span style="font-variant-ligatures:no-common-ligatures">This means the case must be re-opened.</span></div></div></div></blockquote><div><br></div><div>Peter,</div><div><br></div><div>People have been continuing to work on these issues for years. This is not new, and and it is not only now being reopened.</div><div><br></div><div><br></div><div>Unfortunately, at this point I think you are repeating well known and well understood information in email after email. I don't think that is a productive way to discuss this. However, I don't want to dissuade you from contributing to the project. But I don't think new emails on this subject will not be a good use of anyone's time.</div><div><br></div><div>Instead, someone needs to go do the very hard work of building, testing, and understanding solutions to some of these problems. In fact, a few others are already doing exactly this.</div><div><br></div><div>I understand you disagree with the approach others are taking, and that is perfectly fine, even good! You have explained your concern, and there remains a technical disagreement. This is OK. Repeating your position won't really help move forward.</div><div><br></div><div>Contributing technical perspectives (especially different ones!) is always valuable, and I don't want to ever discourage it. But when there remains a strong technical disagreement, we have to find some way to make progress.Typically, LLVM lends weight towards those who have the most significant contributions to LLVM in the area *and* are actually doing the work to realize a path forward. This doesn't make them any more "right" or their opinions "better". It is just about having a path forward.</div><div><br></div><div>But this should also show you how to make progress. Continuing to debate in email probably won't help as you're relatively new to the LLVM project. Instead, write the code, get the data and benchmark results to support your position and approach, and come back to us. I think you will have to do the engineering work of building the solution you want (and others disagree with) and showing why it is objectively better.</div></div></div></div></blockquote></div><br></div></div></div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a></blockquote></div></div></blockquote></div></div><br></div></div></blockquote></div><br></div></div></div>
</div>