[LLVMdev] RFC: Proposal for Poison Semantics

[Philip Reames]

On 01/28/2015 11:29 PM, Sanjoy Das wrote:
>> I don't think your example is actually problematic.  The original program
>> before your transformation *executed* undefined behavior in the form of '%x
>> = add nuw i32 %m, %n' with "%m = %n = 2^32-1 (a.k.a INT_MAX)".  If I
> I was trying to show why the rule "signed overflow is undefined
> behavior" is problematic w.r.t. hoisting arithmetic by repeating an
> argument David made in the first email on this thread.  That
> particular example is not a counterexample to the RFC.
Er, I really don't get your point here.  This is a direct mapping of 
what the C++ spec says onto LLVM IR.  Can you clarify what you mean?
>
> The RFC has issues with icmps, sexts and zexts; but they're distinct
> from the hoisting problem.
Can you enumerate?  Or give an example?
>
>>   %x1 = add nuw i32 %m, %n
>>   %x  = select i1 %cnd x1, 0
>>   %y = zext i32 %x to i64
>>   %s = lshr i64 %y, 32
>>   %addr = gep %some_global, %s
>>   store i32 42, i32* %addr
>>
>> This is well defined as per the spec David sent out.  %x is not poison.  %x1
>> is, but that's fine.
> AFAICT, going by the RFC, %x is poison iff %x1 is poison and %cond is true.
You're correct; I was sloppy in my wording.  What I should have said was 
that %x is poison exactly when the original program would have executed 
undefined behaviour.  If the original program was well defined (and thus 
%cnd is false), %x is not poison.  That seems like exactly what we want.

Philip