<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 27, 2015 at 7:22 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.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"><div class="gmail_extra"><span class=""><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 6:50 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>Examples of this rule which do not result in poison:</div><div>```</div><div>  %or  = or  i32 %always_poison, 2</div><div>  %and = and i32 %always_poison, 2</div><div>  %mul = mul i32 %always_poison, 0</div><div>```</div><div><br></div><div>In fact, it would be reasonable to optimize `%or` to `2` and `%and` to `0`.  In this respect, poison is not different from `undef`.</div></blockquote></div><br></span>The last time we discussed this, we were considering poison a property of an individual bit much like undef is a property of an indivdual bit. Are you no longer proposing those semantics? That is, while %or's second bit is clearly not poison, is the first bit (or LSB) poison?</div></div>
</blockquote></div><br></div><div class="gmail_extra">Sorry this wasn't clear.  My intent was to say that bit 1 was set but that the other bits were poison.  With this in mind, it is legal to throw the poison away if you don't want to keep the or instruction if you replace it with a value which has bit 1 set (these semantics are just like undef).</div></div>