<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="">Chandler,<div class=""> where we disagree is in whether the current project is moving the issue</div><div class="">forward. It is not. It is making the compiler more complex for no additional value.</div><div class=""><br class=""></div><div class="">The current project is not based in evidence, I have asked for any SPEC benchmark</div><div class="">that shows performance gain by the compiler taking advantage of “undefined behavior”</div><div class="">and no one can show that.</div><div class=""><br class=""></div><div class="">The current project doesn’t even address some of the bugs described in the paper,</div><div class="">in particular those derived from the incorrect definition of “undef” in the LangRef.</div><div class=""><br class=""></div><div class="">The current project perpetuates the myth that “poison” is somehow required.</div><div class="">It isn’t, and when I show proof of that you reply with “its in bug reports, etc”,</div><div class="">that’s BS and you know it, this hasn’t been explored. The same thing happened</div><div class="">before when I said “nsw” shouldn’t be hoisted, folks replied with “that’s already</div><div class="">been studied and rejected”, but I did the research and found out no, it had not</div><div class="">been fully explored, Dan discarded the idea based on incorrect analysis and people</div><div class="">never questioned it. Dan created “poison” on a whim, and people picked up on it too</div><div class="">without question. We’ve been stuck with this self-inflicted wound ever since, and it is</div><div class="">time to heal it.</div><div class=""><br class=""></div><div class="">The entire situation here can be summarized as incorrect analysis, and failure to</div><div class="">fully root-cause problems, because people didn’t question their assumptions.</div><div class="">And we should not be surprised, it is one of the most common problems in software </div><div class="">engineering. Haven’t you ever gone in to fix a bug only to find that what you are doing</div><div class="">is correcting someone else’s bug fix that didn’t actually fix anything because the person</div><div class="">doing the fix didn’t fully understand the problem? Happens to me all the time.</div><div class=""><br class=""></div><div class="">The correct software engineering decision here is to fix the definition of “undef”,</div><div class="">delete “poison”, and not hoist “nsw” attributes. That is a no-brainer. There is nothing</div><div class="">to try out, or test, ormeasure. That is simply the way it has to be to avoid the current </div><div class="">set of problems.</div><div class=""><br class=""></div><div class="">I cannot emphasize that last point enough, fixing the definition of “undef”, deleting</div><div class="">“poison”, and not allowing “nsw” attributes to be hoisted, fixes all known problems,</div><div class="">even including ones that weren’t thought of before these discussions started, and</div><div class="">I don’t think there is any technical disagreement here, not even from John, Sanjoy,</div><div class="">or Nuno. This is a no-brainer.</div><div class=""><br class=""></div><div class="">John and I do not have a technical disagreement, John is having an emotional</div><div class="">reaction to the fact that he doesn’t have an answer to the function-inlining question.</div><div class="">We can’t disagree until he actually has an opinion to disagree with, but he is not</div><div class="">willing to express one.</div><div class=""><br class=""></div><div class="">The work on “poison” and “freeze” should be in new analysis and transform passes</div><div class="">in which folks can do whatever they want to propagate “undefined behavior” around</div><div class="">in a function (but “undefined behavior" should be an analysis attribute not an IR</div><div class="">instruction). Then folks can try to see if they can actually measure a performance gain</div><div class="">on any SPEC benchmarks. I think we all know this is going to turn out negative, but that’s</div><div class="">besides the point, the point is that “poison” and “freeze” are an experiment and need </div><div class="">to be treated as such and not just simply forced into the trunk because someone likes it.</div><div class=""><br class=""></div><div class="">What you are saying about ’the llvm way" goes against everything we know about</div><div class="">"software engineering”, that things have to be evidence based, have utility, and</div><div class="">be the least complex solution to avoid confusion. And we do engineering reviews</div><div class="">and take review feedback seriously. I suggest you take a step back and think about</div><div class="">that, because it sure seems to me like you’re advocating that we don’t do reviews and</div><div class="">we don’t base decisions on evidence.</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><blockquote type="cite" class=""><div class="">On Jun 28, 2017, at 12:16 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="">chandlerc@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=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jun 28, 2017 at 9:39 AM Peter Lawrence <<a href="mailto:peterl95124@sbcglobal.net" class="">peterl95124@sbcglobal.net</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;"><div style="word-wrap: break-word;" class=""><div dir="auto" style="word-wrap: break-word;" class=""><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255); min-height: 16px;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">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;" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""></span><br class=""></div><div style="margin: 0px; font-size: 14px; line-height: normal; font-family: Menlo; background-color: rgb(255, 255, 255);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class="">This means the case must be re-opened.</span></div></div></div></blockquote><div class=""><br class=""></div><div class="">Peter,</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""></div></body></html>