[LLVMdev] RFC: Proposal for Poison Semantics

[Sanjoy Das]

> 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.  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.

-- Sanjoy