<div dir="ltr">I think the simpler way of phrasing 1 is: "poison has the same propagation rules as undef". This means that poison is a property of bits, not of values, and basic arithmetic like 'and 0', 'or 1', and 'mul 0' can mask it away. This makes a CFG diamond equivalent to a select and select equivalent to arithmetic, which seems like general goodness. I wonder if we lose optimization power around these kinds of masking arithmetic instructions, though.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 23, 2014 at 2:16 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think that there are fundamentally two different solutions to the select-poison issue with their own pros and cons:<div><br></div><div>Either:</div><div><br></div><div>We allow instructions to not care about poison operands because their output will not contain any information tainted by the poison. This would mean that select is allowed to ignore a poisoned operand if it doesn't select it. It would also mean that a poison condition value guarantees that you get *one* of the two operands *but* that the select instruction itself has been poisoned.</div><div><br></div><div>AFAICT, this doesn't lose out on any optimizations.</div><div><br></div><div><br></div><div>Or:</div><div><br></div><div>We introduce a 'vile' attribute to the select instruction. A 'vile' select is poison even if the operand which wasn't selected if poison while 'normal' selects behave more like br/phi instructions.</div><div><br></div><div>This is a more conservative and, IMO, uglier approach which is sound but would require auditing LLVM to make sure that it only transforms 'vile' selects into arithmetic. I think it would be very hard to optimize a normal select into a 'vile' select which would mean that we might lose out on some optimizations.</div><div><br></div><div><br></div><div>If there is a reason we shouldn't go with approach #1? I can't immediately come up with IR that we would stop optimizing.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 23, 2014 at 12:03 AM, 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">Hi,<br>
<span><br>
> Does this make any sense at all? Have there been past attempts at<br>
> formalizing poison along these lines?<br>
<br>
</span>Answering my own question, what I was considering is a slight variant<br>
of the scheme mentioned in an earlier email by Dan:<br>
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045730.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045730.html</a><br>
<br>
"<br>
- Instead of trying to define dependence in LangRef, just say that if<br>
changing the value returned from an overflowing add nsw would<br>
affect the observable behavior of the program, then the behavior of<br>
the program is undefined. This would reduce the amount of text in<br>
LangRef, but it would be a weaker definition, and it would require<br>
sign-extension optimizers and others to do significantly more work<br>
to establish that their transformations are safe.<br>
"<br>
<br>
That said, this scheme does not work as expected -- the bitness of the<br>
result of an overflowing add prevents some optimizations:<br>
<br>
%a = add nsw i32 %v, 1<br>
%c = icmp slt i32 %v, %a<br>
store %c, < global variable ><br>
<br>
In the case of signed overflow, %v is INT32_MAX. For all values of<br>
%a, the observable behavior of the program is the same (we store false<br>
to < global variable > for all values of %a); and so we cannot exploit<br>
undefined behavior and simplify '%c' to true.<br>
<br>
Similar issues arise if you, for example, zero extend a poison value,<br>
and then right shift out all the "poison bits" -- the resulting value<br>
is all zeroes and do not capture overflowing semantics.<br>
<br>
Thanks,<br>
-- Sanjoy<br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div>