<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="">Sanjoy,<div class=""> Sorry, I guess I wasn’t specific enough, I’ll try again. Excerpt from your blog post:</div><div class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>"<span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class="">Another way to look at this is that </span><code style="color: rgb(68, 68, 68); padding: 1px 5px;" class="">undef</code><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class=""> isn’t a normal SSA value, and </span><em style="color: rgb(68, 68, 68);" class="">uses</em><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class=""> of an </span><code style="color: rgb(68, 68, 68); padding: 1px 5px;" class="">undef</code><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class="">value are also its </span><em style="color: rgb(68, 68, 68);" class="">defs</em><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class="">.</span><font color="#444444" class="">”</font></div><div class=""><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class=""><br class=""></span></div><div class=""><span style="color: rgb(68, 68, 68); background-color: rgb(255, 255, 255);" class="">IMHO this was a bad definition from the get-go.</span></div></div><div class=""><br class=""></div><div class=""><div class="">It seems to me that transforming a program with multiple uses of a single undefined variable</div><div class="">into one with multiple distinct IR “undef”s results in behavior that is inconsistent, and that</div><div class="">violates users expectations, and therefore we should not do it.</div><div class=""><br class=""></div><div class="">In other words the aspect of the current definition of “undef” in LLVM-IR that seems to force</div><div class="">programs with undefined variables to be mis-represented is broken, and the definition of “undef"</div><div class="">needs to be fixed.</div><div class=""><br class=""></div><div class="">Your proposal with “freeze” makes it possible to force all uses of an undefined variable to be</div></div><div class="">consistent, but why not just do the simpler fix to “undef” / “poison” and allow them to have</div><div class="">multiple uses, as opposed to “use once only, by definition of the IR”, which does not seem</div><div class="">to have any benefit.</div><div class=""><br class=""></div><div class="">So again, “freeze” seems to be a workaround, rather than fixing the underlying problem.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thoughts ?</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><blockquote type="cite" class=""><div class="">On Jun 8, 2017, at 1:29 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" class="">sanjoy@playingwithpointers.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">On Thu, Jun 8, 2017 at 12:29 PM, Peter Lawrence<br class=""><<a href="mailto:peterl95124@sbcglobal.net" class="">peterl95124@sbcglobal.net</a>> wrote:<br class=""><blockquote type="cite" class=""><br class="">Sanjoy,<br class=""> in your blog post<br class=""><a href="https://www.playingwithpointers.com/problem-with-undef.html" class="">https://www.playingwithpointers.com/problem-with-undef.html</a><br class="">you describe a problem with LLVM “undef”,<br class="">yet in your paper http://www.cs.utah.edu/~regehr/papers/undef-pldi17.pdf<br class="">you do not suggest fixing this problem, even though in chpt. 9 you identify<br class="">other<br class="">compilers that do attempt to avoid it.<br class=""></blockquote><br class="">That problem is mentioned in section 3.2 (which quotes the same<br class="">example as in the blog post), and section 4 (the paragraph starting<br class="">with "Defining branching on poison to be UB further enables analyses<br class="">to assume that...") addresses how the new semantics plugs this gap.<br class=""><br class=""><blockquote type="cite" class="">The reason I keep asking for additional examples is that this one where<br class="">You have illegally transformed the ‘nsw’ isn’t convincing. So please,<br class=""></blockquote><br class="">Maybe we're talking past each other. Let me first discuss the framing<br class="">of the problem as I see it:<br class=""><br class=""> 1. Whether a transform is illegal or not is decided by the semantics<br class=""> we've assigned to the IR. In this case, whether hoisting the<br class=""> multiplication with the nsw intact is illegal or not is decided by<br class=""> the semantics we've assigned to nsw.<br class=""><br class=""> 2. We want certain transforms to be legal, which limits the kinds of<br class=""> semantics we can possibly have for the IR. For instance, we<br class=""> certainly don't want a semantics for IR that disallows constant<br class=""> folding `add i32 1, 2`.<br class=""><br class="">The example I gave was to demonstrate why the current (albeit not very<br class="">clearly specified) semantics is incorrect.<br class=""><br class="">So when you ask for an example, are you asking why the set of<br class="">transforms we want to be correct in the new semantics (i.e. (2))<br class="">includes "hoist nsw-arithmetic out of control flow while still keeping<br class="">the flags"? IOW, in the language used in the paper I linked to, are<br class="">you asking "why can't we have a overflowing nsw addition be immediate<br class="">UB"? If so, that is covered in section 2.2 (but we can get into more<br class="">detail if you want).<br class=""><br class="">-- Sanjoy<br class=""></div></div></blockquote></div><br class=""></div></body></html>