<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 8:58 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="">> Ah, yes.  You are right, we cannot always assume that %y would be zero in<br>
> the second case.<br>
> This wouldn't be the first time we've lost information that we could use to<br>
> optimize a program by transforming it.<br>
><br>
> Do you think this result would be problematic?  It seems consistent with the<br>
> RFC and LLVM's current behavior.<br>
><br>
<br>
</span>The problem is not that we're losing information, the problem is that<br>
we're changing the behavior of a well-defined program.<br>
<br>
I'll try to put the whole argument in one place:<br>
<br>
We start with<br>
<br>
  %x = add nuw i32 %m, %n<br>
  %y = zext i32 %x to i64<br>
  %s = lshr i64 %y, 32<br>
  %addr = gep %some_global, %s<br>
  store i32 42, i32* %addr<br>
<br>
In the above program, for all values of %x, %s is 0.  This means the<br>
program is well-defined when %x is poison (since you don't need to<br>
look at %x to determine the value of %addr, in the same sense as you<br>
don't need to look at X to determine the value of "and X, 0"); and it<br>
stores 42 to &(%some_global)[0].  Specifically, the above program is<br>
well defined for "%m = %n = 2^32-1".</blockquote></div><br>I don't follow this last sentence.</div><div class="gmail_extra"><br></div><div class="gmail_extra">if the definition of NUW is that zext-ing the result is equivalent to zext-ing the inputs and doing the operation at a higher bitwidth (my understanding), then %m and %n cannot hold those values, that would violate the NUW flag.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Either my understanding of th edefinition holds, or the transformation you are proposing isn't valid IMO.</div></div>