[LLVMdev] Proposal for Poison Semantics

[Nuno Lopes]

>> I think such a thing would be great.  However, there is a problem that 
>> the RFC wasn't aware of when it was
>> written:
>> 
>> consider:
>> %S = select %A, %B, undef
>> 
>> without us knowing anything about %A or %B, we will replace all uses 
>> of %S with %B.  This transform would be considered wrong with the RFC in mind.
>> 
>> If this transform was valid, there could not be any value or 
>> value-like property in LLVM with semantics more powerful than undef.  
>> This makes me think that what LLVM *actually* implements is not poison or something like it.
> 
>Is it possible that the new weaker poison subsumes undef?  The interaction between these different but related UB-like concepts is confusing at best.

That's a good point!
AFAICT there are only 2 differences between undef and poison:
 1) poison can trigger UB at some point in the future.
 2) the behavior of sext (and zext?) is different (copying the sign bit vs adding poison bits)

(read more about 2) at http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045730.html)


Right now. I think the only places that generate undef are reads of uninitialized variables, and I can't remember of any other.  If that's the case, it's fair to ask why can't we use poison for everything?
Reading uninitialized memory is undefined behavior, so in theory we could return a poison value.  On the other hand, the behavior may look strange at times. Imagine the following:

%a = load i4* %ptr
%b = sext %a to i8
%c = and %b, 0x8080

If %a returns undef, then %c can only be 0 or 0x8080 (because it copies the sign). If %a is poison, then %c can be any of the 4 combinations.
The developer may not expect this behavior.  But, anyway, UB was executed, so not our problem..

Nuno