<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-21 21:27 GMT-07:00 Peter Lawrence <span dir="ltr"><<a href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><font face="Menlo">Sean,</font><div><font face="Menlo">     Let me re-phrase a couple words to make it perfectly clear</font></div><div><br><div><span class=""><blockquote type="cite"><div><font face="Menlo">On Jul 21, 2017, at 6:29 PM, Peter Lawrence <<a href="mailto:peterl95124@sbcglobal.net" target="_blank">peterl95124@sbcglobal.net</a>> wrote:</font></div><font face="Menlo"><br class="m_2150444843056015504Apple-interchange-newline"></font><div><div style="word-wrap:break-word"><font face="Menlo">Sean,</font><div><font face="Menlo"><br></font></div><div><font face="Menlo">Dan Gohman’s “transform” changes a loop induction variable, but does not change the CFG,</font></div><div><font face="Menlo"><br></font></div><div><font face="Menlo">Hal’s “transform” deletes blocks out of the CFG, fundamentally altering it.</font></div><div><font face="Menlo"><br></font></div><div><span style="font-family:Menlo">These are two totally different transforms.</span></div></div></div></blockquote><blockquote type="cite"><div style="word-wrap:break-word"><div><br></div><div><span style="font-family:Menlo"><br></span></div></div></blockquote><blockquote type="cite"><div><div style="word-wrap:break-word"><div><font face="Menlo">And even the analysis is different,</font></div><div><font face="Menlo"><br></font></div><div><font face="Menlo">The first is based on an *assumption* of non-UB (actually there is no analysis to perform)</font></div></div></div></blockquote></span><font face="Menlo">                       the *absence* of UB<br></font><span class=""><blockquote type="cite"><div style="word-wrap:break-word"><div><font face="Menlo"><br></font></div><div><font face="Menlo">the second Is based on a *proof* of existence of UB (here typically some non-trivial analysis is required)</font></div></div></blockquote></span><font face="Menlo">                        the *presence* of UB<br></font><span class=""><br><blockquote type="cite"><div style="word-wrap:break-word"><div><font face="Menlo">These have, practically speaking, nothing in common.</font></div><div><font face="Menlo"><br></font></div></div></blockquote><div><br></div><div><br></div></span><div><font face="Menlo">In particular, the first is an optimization, while the second is a transformation that</font></div><div><font face="Menlo">fails to be an optimization because the opportunity for it happening in real world</font></div><div><font face="Menlo">code that is expected to pass compilation without warnings, static analysis without</font></div><div><font face="Menlo">warnings, and dynamic sanitizers without warnings, is zero.</font></div><div><font face="Menlo"><br></font></div><div><font face="Menlo">Or to put it another way, if llvm manages to find some UB that no analyzer or</font></div><div><font face="Menlo">sanitizer does, and then deletes the UB, then the author of that part of llvm</font></div><div><font face="Menlo">is in the wrong group, and belongs over in the analyzer and/or sanitizer group.</font></div></div></div></div></blockquote><div><br></div><div>I don't understand your claim, it does not match at all my understand of what we managed to get on agreement on in the past.</div><div><br></div><div>The second transformation (dead code elimination to simplify) is based on the assumption that there is no UB.</div><div><br></div><div>I.e. after inlining for example, the extra context of the calling function allows us to deduce the value of some conditional branching in the inline body based on the impossibility of one of the path *in the context of this particular caller*.</div><div><br></div><div>This does not mean that the program written by the programmer has any UB inside.</div><div><br></div><div>This is exactly the example that Hal gave.</div><div><br></div><div>This can't be used to expose any meaningful information to the programmer, because it would be full of false positive. Basically a program could be clean of any static analyzer error, of any UBSAN error, and totally UB-free, and still exhibit tons and tons of such issues.</div><div><br></div><div>-- </div><div>Mehdi</div></div></div></div>