[LLVMdev] RFC: Proposal for Poison Semantics

[Chandler Carruth]

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

> > 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.
> >
>
> The problem is not that we're losing information, the problem is that
> we're changing the behavior of a well-defined program.
>
> I'll try to put the whole argument in one place:
>
> We start with
>
>   %x = add nuw i32 %m, %n
>   %y = zext i32 %x to i64
>   %s = lshr i64 %y, 32
>   %addr = gep %some_global, %s
>   store i32 42, i32* %addr
>
> In the above program, for all values of %x, %s is 0.  This means the
> program is well-defined when %x is poison (since you don't need to
> look at %x to determine the value of %addr, in the same sense as you
> don't need to look at X to determine the value of "and X, 0"); and it
> stores 42 to &(%some_global)[0].  Specifically, the above program is
> well defined for "%m = %n = 2^32-1".


I don't follow this last sentence.

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.

Either my understanding of th edefinition holds, or the transformation you
are proposing isn't valid IMO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/bd36ea4b/attachment.html>