[LLVMdev] RFC: Proposal for Poison Semantics

[Chandler Carruth]

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

> > 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.
>
> The problem to solve is adequately defining "cannot hold".  In the
> strictest sense, you could say if %m = %n = 2^31 - 1 then the program
> has UB; in effect defining "cannot hold" in the same way a location
> you're loading from "cannot be" non-deferenceable.  But, as David points
> out, that would mean you cannot hoist arithmetic with the nuw/nsw tags
> intact:
>
>   if (foo)
>    %t = add nuw X Y
>
> since it could be that (X != 2^32-1 && Y != 2^32-1) only if foo ==
> true.  Arithmetic with no-wrap flags effectively are side-effecting
> operations in this scheme.
>
> The RFC tries to formalize a weaker notion of "cannot hold" that
> justifies treating arithmetic like arithmetic.


Yes, quite familiar.


>   I'm trying to show
> that the notion of poison value in this RFC is too weak; and allows
> for certain programs to be well-defined (like the example I just
> showed) which change meaning in the face of transforms we'd like to be
> able to do.


I see, this is a case where the RFC as it stands strips poison too soon.

Going to ponder this, I feel like this should be something we can
incorporate into the model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150127/dcc58ff9/attachment.html>