[LLVMdev] RFC: Proposal for Poison Semantics

[David Majnemer]

On Tue, Jan 27, 2015 at 8:32 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> >
> > Correct me if I am wrong but we are talking about transforming:
> >    %maybe_poison = add nuw i32 %a, %b
> >    %x = zext i32 %maybe_poison to i64
> >    %y = lshr i64 %x 32
> >
> > To:
> >    %za = zext i32 %a to i64
> >    %zb = zext i32 %b to i64
> >    %x = add nuw i64 %za, %zb
> >    %y = lshr i64 %x 32
> >
> > ?
> >
> > If so, this seems fine in the model given by the RFC.
> >
> > In the before case:
> > %maybe_poison doesn't infect the upper bits of %x with its poison which
> > allows %y to have the well defined result 0.
> >
> > In the after case:
> > %za and %zb will have their top 32-bits filled with zeros making it
> > impossible for nuw to be violated for %x, %y would have the well defined
> > result 0.
> >
>
> If both %a and %b are 2^32-1, won't %y be 0 in the first case and 1 in
> the second?


Ah, yes.  You are right, we cannot always assume that %y would be zero in
the second case.
This wouldn't be the first time we've lost information that we could use to
optimize a program by transforming it.

Do you think this result would be problematic?  It seems consistent with
the RFC and LLVM's current behavior.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/e67366c6/attachment.html>