<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 8, 2014 at 10:23 PM, Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>>> I'm pretty sure the LangRef has a bug here.  It cannot literally mean<br>
>>> undefined behavior or the program hits UB once an add nsw that produces<br>
>>> poison is used as the operand to another add.<br>
><br>
> Why is this a problem?<br>
<br>
</span>Answering my own question (sorry for being thick the first time<br>
around), this is a problem because it prevents the transform "(x + 2)<br>
=> ((x + 1) + 1)".<br>
<br>
However, how about splitting LLVM's instruction set into instructions<br>
that propagate poison (like add, and lshr) and instructions that trap<br>
on poison (like udiv, load, call and store)?  This allows us to<br>
optimize "t < (t + 1)" to "true" (the < is UB if (t + 1) overflows),<br>
allows usual reordering of exprs composed only of ops from the first<br>
set (I think!) and allows us to conclude that, say, a load can never<br>
be poison (since the store that stored poison is UB).<br></blockquote><div><br></div><div><br></div><div>I don't think those instructions aren't the problematic ones.  To me, select is the real deal beaker for poison.</div><div><br></div><div>If a poison value enters select, is the entire select poisoned?</div><div>If not, that means select can _never_ be decomposed into arithmetic because arithmetic propagates poison.</div><div>If so, then we can only turn phi-br into select when we are sure neither operand of select is poison.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
-- Sanjoy<br>
</font></span></blockquote></div><br></div></div>