<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 4, 2015 at 9:13 AM, John Regehr <span dir="ltr"><<a href="mailto:regehr@cs.utah.edu" target="_blank">regehr@cs.utah.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think such a thing would be great.  However, there is a problem that the RFC wasn't aware of when it was<br>
written:<br>
<br>
consider:<br>
%S = select %A, %B, undef<br>
<br>
without us knowing anything about %A or %B, we will replace all uses of %S with %B.  This transform would be<br>
considered wrong with the RFC in mind.<br>
<br>
If this transform was valid, there could not be any value or value-like property in LLVM with semantics more<br>
powerful than undef.  This makes me think that what LLVM *actually* implements is not poison or something like<br>
it.<br>
</blockquote>
<br></span>
Is it possible that the new weaker poison subsumes undef?  The interaction between these different but related UB-like concepts is confusing at best.</blockquote><div><br></div><div>I am actively working towards removing poison altogether.  I think a more accurate model of LLVM's wrapping flags is not poison but instead something akin to the fast-math flags on floating point instructions.</div><div> </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>
<br>
John<br>
</font></span></blockquote></div><br></div></div>