<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 9:38 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="">> if the definition of NUW is that zext-ing the result is equivalent to<br>
> zext-ing the inputs and doing the operation at a higher bitwidth (my<br>
> understanding), then %m and %n cannot hold those values, that would violate<br>
> the NUW flag.<br>
<br>
</span>The problem to solve is adequately defining "cannot hold".  In the<br>
strictest sense, you could say if %m = %n = 2^31 - 1 then the program<br>
has UB; in effect defining "cannot hold" in the same way a location<br>
you're loading from "cannot be" non-deferenceable.  But, as David points<br>
out, that would mean you cannot hoist arithmetic with the nuw/nsw tags<br>
intact:<br>
<br>
  if (foo)<br>
   %t = add nuw X Y<br>
<br>
since it could be that (X != 2^32-1 && Y != 2^32-1) only if foo ==<br>
true.  Arithmetic with no-wrap flags effectively are side-effecting<br>
operations in this scheme.<br>
<br>
The RFC tries to formalize a weaker notion of "cannot hold" that<br>
justifies treating arithmetic like arithmetic.</blockquote><div><br></div><div>Yes, quite familiar.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  I'm trying to show<br>
that the notion of poison value in this RFC is too weak; and allows<br>
for certain programs to be well-defined (like the example I just<br>
showed) which change meaning in the face of transforms we'd like to be<br>
able to do.</blockquote></div><br>I see, this is a case where the RFC as it stands strips poison too soon.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Going to ponder this, I feel like this should be something we can incorporate into the model.</div></div>