[llvm-dev] RFC: Killing undef and spreading poison

[Sanjoy Das via llvm-dev]

Hi Nuno,

Nuno Lopes wrote:
  > Right, that's a very good point. We already have this problem today 
as well, though.
 > We can translate this into a select by using freeze, as you say 
(that's exactly for these cases why we are proposing to introduce freeze).
 > What we need to settle on, and we didn't touch this on our proposal, 
is how LLVM's analyses API will look like. Most (if not all) LLVM 
analyses today report a result that doesn't exclude that the value might 
be poison.  That's because if you report %v to be non-null and it's 
actually poison it's fine since poison can be restricted to be non-null. 
  We will need to introduce a isNotPoison() analysis and a 
ensureIsNonPoison() utility (that needs to be used by all 
transformations doing speculation).
 > I would freeze %y. What's the argument against?

frozen %y can be zero if %x (and thus %y) is poison.

ensureIsNonPoison will have to work in concert with whatever inferred
%y to be non-zero.



What follows is rather vague, so take with a pinch of salt:

However, I don't think there is an easy way to solve the problem Dan
pointed out (beyond "freeze the right things") as long as both of
these hold:

  1. We infer properties for values based on how they're computed (i.e.
     (or X 1) != 0).

  2. We allow behavior that cannot be explained by assigning to each
     SSA register a value that is legal in the type of the SSA
     register.

What I mean by this is, say you have:

   %val0 = load ...
   %val1 = load ...
   %result = add nsw i32 %val0, %val1
   %result.sext = sext %result to i64

The high 32 bits of %result.sext have to be 0 or -1 because it is
computed via a sext (by (1)).  However if we commute the sext through
the addition (because %result is nsw, and you want to exploit (2))
then that is no longer true.  That is, Once you've assumed that the
high 32 bits of %result.sext are 0 or -1, then you fundamentally
_need_ an optimization barrier to prevent (2) from occurring.

-- Sanjoy