<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 8:32 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="">><br>
> Correct me if I am wrong but we are talking about transforming:<br>
>    %maybe_poison = add nuw i32 %a, %b<br>
>    %x = zext i32 %maybe_poison to i64<br>
>    %y = lshr i64 %x 32<br>
><br>
> To:<br>
>    %za = zext i32 %a to i64<br>
>    %zb = zext i32 %b to i64<br>
>    %x = add nuw i64 %za, %zb<br>
>    %y = lshr i64 %x 32<br>
><br>
> ?<br>
><br>
> If so, this seems fine in the model given by the RFC.<br>
><br>
> In the before case:<br>
> %maybe_poison doesn't infect the upper bits of %x with its poison which<br>
> allows %y to have the well defined result 0.<br>
><br>
> In the after case:<br>
> %za and %zb will have their top 32-bits filled with zeros making it<br>
> impossible for nuw to be violated for %x, %y would have the well defined<br>
> result 0.<br>
><br>
<br>
</span>If both %a and %b are 2^32-1, won't %y be 0 in the first case and 1 in<br>
the second?</blockquote><div><br></div><div>Ah, yes.  You are right, we cannot always assume that %y would be zero in the second case.</div><div>This wouldn't be the first time we've lost information that we could use to optimize a program by transforming it.</div><div><br></div><div>Do you think this result would be problematic?  It seems consistent with the RFC and LLVM's current behavior.</div><div><br></div></div></div></div>