[LLVMdev] RFC: Proposal for Poison Semantics

[Sanjoy Das]

On Thu, Jan 29, 2015 at 10:33 AM, Philip Reames
<listmail at philipreames.com> wrote:
>
> 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?

I mean if the specification of nsw (say) in LLVM is "add nsw X Y" is
undefined behavior if the addition overflows, then we cannot hoist
additions through control flow since we could be introducing undefined
behavior that wasn't present in the original program.  Hence it is
undesirable to state "add nsw X Y has UB if the addition overflows".
The RFC does not formalize nsw this way, so this is not a problem with
the RFC.


> Can you enumerate?  Or give an example?

I've given (counter-)examples for all of these in previous emails:

[zext] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081321.html
+ http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081322.html

[sext] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081316.html

[icmp] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/081312.html

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

Yes, this RFC does the right thing in this case.

-- Sanjoy