<div dir="ltr">Peter, I'm a bit mystified by your response. I thought Sanjoy did a pretty good job giving answers to your technical questions. Sanjoy's response was a bit terse on the technical points, so maybe I can elaborate a bit more.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 29, 2017 at 12:08 AM, Peter Lawrence via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></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">Sanjoy,<div>            you seem to be changing your story, when I first brought up the </div><div>function-inlining example you argued about how I should not use C/C++ for such</div><div>programs, and that you were not fixing it for some reason related to how the IR is an</div><div>abstraction and C/C++ wasn’t your problem, I pushed you on the issue by saying</div><div>so lets translate the C example into IR and then talk about it, you went silent</div><div>after that. No response.</div></div></blockquote><div><br></div><div>This is the same issue as transforming `mul %x, 2` ==> `add %x, %x` described in section 3.1 "Duplicate SSA Uses" of the paper. It is definitely a problem with undef, as you rightly point out. The basic problem is that the `undef` value has weird semantics where it has different values at each *use*.</div><div>The paper's proposed semantics do solve this.</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>Same thing when I brought up the not hoisting a loop invariant divide out of</div><div>a loop, you were silent about that, leading me to believe that you were not</div><div>addressing that either.</div></div></blockquote><div><br></div><div>This is another thing that the paper's proposed semantics fixe, and is related to a point that I think you found confusing in another thread, namely, why the proposed semantics treat branch-on-poison as immediate UB. The paper does say</div><div><br></div><div>"""</div><div><div>Defining branching on poison to be UB further enables</div><div>analyses to assume that predicates used on branches hold</div><div>within the target basic block, which would not be possible if</div><div>we had defined branching on poison to be a non-deterministic</div><div>choice. For example, for code like if (x > 0) { /* foo</div><div>*/ }, we want to allow analyses to assume that x is positive</div><div>within the “then” block (and not positive in the “else” block).</div></div><div>"""</div><div><br></div><div>This is fairly terse, but I think is clear. This is how the proposed semantics can handle these scenarios even in the face of such a "dangerous" value as poison. I have to admit, it does leave me thinking (as I think it leaves you thinking): if we have to do this just to propagate branch predicates along control flow edges, then what else are we going to have to do to keep poison under control?</div><div>I honestly don't know. I haven't thought about it that much. Possibly the answer is that there aren't any other holes. I haven't thought about it deeply, but I know the folks working on this and they're pretty smart and *have* thought about it deeply, so I'm not in a rush to shoot down their proposal.</div><div><br></div><div>But maybe you are, and that's fine. (Sanjoy has a knack for finding holes in proposed semantics; we've seen that again and again and I doubt he does it by trusting that proposal is hole-free :P )</div><div><br></div><div>However, so far, none of your posts look to me like they poke holes in their proposal. It sounds like you are effectively thinking of an alternative proposal, though I think that the discussion has gotten very fragmented and unfocused over multiple threads. As Sanjoy distilled, it sounds like what you want is:</div><div><br></div><div>"""</div><div><div> - An undef "instruction"</div><div> - Undefined behavior on a overflowing nsw/nuw arithmetic (equivalent</div><div>to "strip nsw/nuw on hoisting")<br>"""</div></div><div><br></div><div>Does this correctly summarize the direction you want LLVM to go? They sounds like a perfectly consistent semantics, but personally it sounds to me like it makes hoisting SSA values past control flow more difficult, possibly requiring an huge (possibly infeasible) amount of churn to LLVM's passes to actually perform the transformations as your proposed semantics would require. I'd really need to see a prototype to be convinced otherwise, and I think the others in this thread do too.</div><div>In fact, I think that this proposal would actually introduce more complexity than the freeze/poison proposal as transformations would likely have to use some utility to ensure that nsw/nuw are appropriately stripped if things move past control flow (possibly even otherwise control-oblivious transformations).</div><div><br></div><div>-- Sean Silva</div><div> </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>What changed ?</div><span class="gmail-m_7640461418786065878gmail-HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Peter Lawrence.</div></font></span><span class="gmail-m_7640461418786065878gmail-"><div><br></div><div><br></div><div><br><div><blockquote type="cite"><div>On Jun 28, 2017, at 11:26 PM, Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.co<wbr>m</a>> wrote:</div><br class="gmail-m_7640461418786065878gmail-m_-640742836634444211Apple-interchange-newline"><div><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"><span 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;float:none;display:inline">is radically different from where LLVM is right now and the burden is</span><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"><span 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;float:none;display:inline">on you to show that this end result is realistic.  The biggest hurdle</span><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"><span 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;float:none;display:inline">of the new semantics was implementing it (many thanks to Juyeyoung Lee</span><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"><span 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;float:none;display:inline">who did most of the hard work) to show that it actually works and does</span><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"><span 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;float:none;display:inline">not regress performance.  You need to do the same thing for your</span><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"><span 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;float:none;display:inline">proposal to sit at the same table.</span><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"><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"><span 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;float:none;display:inline">-- Sanjoy</span></div></blockquote></div><br></div></span></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><br>
<br></blockquote></div><br></div></div>