llvm dev - Apr 2016 - Is trapping allowed when an add with nsw flag overflows?

[This mail could be an answer to the other responses as well, as they 
basically are the same.]

Ah, I think I understand now what poison is for.  Adds are defined to 
not have side-effects, so the dependence rule is needed so the optimizer 
is allowed to exploit undefined behavior.  Is this correct?

I forgot to mention in my original mail that our trapping arithmetic 
operations are fully speculable.  This means that the trap won't happen 
until the result is e.g. stored to memory.  A bit like poison values in 
hardware.

Something is still unclear to me: while, according to the examples in 
LangRef, a volatile store has undefined behavior when a poison value is 
stored, this seems to not be true in case of non-volatile stores.  Can 
someone clarify please?

On 2016-04-15 19:44, John Regehr via llvm-dev wrote:
> No, trapping is not allowed, since an overflowing add nsw is defined
> to produce a poison value, which sort of explodes into undefined
> behavior if it reaches a side-effect.  This is to support speculative
> execution.
> 
> If you emit trapping adds for nsw, you'll see spurious traps every now 
> and then.
> 
> There's a stronger form of undefined behavior, exhibited by things
> like divide by zero, that permits traps.
> 
> John
> 
> 
> 
> On 4/15/16 7:28 PM, Manuel Jacob via llvm-dev wrote:
>> Hi,
>> 
>> In our backend, we currently emit add operations that trap on overflow
>> if the IR operation has the nsw flag set.  Is this allowed?
>> 
>> According to the documentation about poison values, overflowing a nsw
>> add is undefined behavior.  However I didn't find a formal
definition
>> of
>> undefined behavior in LLVM.  Judging from previous discussions on the
>> mailing list, there seems to be a vague line of what LLVM is allowed 
>> to
>> do in case of undefined behavior.  Is trapping allowed?
>> 
>> -Manuel

It comes down to observability.  It's fine to store poison into a memory
location and load it back; however, the optimizer is free to delete stores
of poison.  What is not ok is depending on the value of a load of a poison
value in code which may have observable results (volatile, system calls,
etc.).

On Mon, Apr 18, 2016 at 11:18 AM, Manuel Jacob <me at manueljacob.de>
wrote:
> [This mail could be an answer to the other responses as well, as they
> basically are the same.]
>
> Ah, I think I understand now what poison is for.  Adds are defined to not
> have side-effects, so the dependence rule is needed so the optimizer is
> allowed to exploit undefined behavior.  Is this correct?
>
> I forgot to mention in my original mail that our trapping arithmetic
> operations are fully speculable.  This means that the trap won't happen
> until the result is e.g. stored to memory.  A bit like poison values in
> hardware.
>
> Something is still unclear to me: while, according to the examples in
> LangRef, a volatile store has undefined behavior when a poison value is
> stored, this seems to not be true in case of non-volatile stores.  Can
> someone clarify please?
>
>
> On 2016-04-15 19:44, John Regehr via llvm-dev wrote:
>
>> No, trapping is not allowed, since an overflowing add nsw is defined
>> to produce a poison value, which sort of explodes into undefined
>> behavior if it reaches a side-effect.  This is to support speculative
>> execution.
>>
>> If you emit trapping adds for nsw, you'll see spurious traps every
now
>> and then.
>>
>> There's a stronger form of undefined behavior, exhibited by things
>> like divide by zero, that permits traps.
>>
>> John
>>
>>
>>
>> On 4/15/16 7:28 PM, Manuel Jacob via llvm-dev wrote:
>>
>>> Hi,
>>>
>>> In our backend, we currently emit add operations that trap on
overflow
>>> if the IR operation has the nsw flag set.  Is this allowed?
>>>
>>> According to the documentation about poison values, overflowing a
nsw
>>> add is undefined behavior.  However I didn't find a formal
definition of
>>> undefined behavior in LLVM.  Judging from previous discussions on
the
>>> mailing list, there seems to be a vague line of what LLVM is
allowed to
>>> do in case of undefined behavior.  Is trapping allowed?
>>>
>>> -Manuel
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/af8f0266/attachment.html>

On 2016-04-18 18:19, David Majnemer wrote:
> It comes down to observability.  It's fine to store poison into a 
> memory
> location and load it back; however, the optimizer is free to delete 
> stores
> of poison.  What is not ok is depending on the value of a load of a 
> poison
> value in code which may have observable results (volatile, system 
> calls,
> etc.).
Thank you for the clarification.

To take up the initial question, is trapping OK when a non-volatile 
store stores a poison value?
> On Mon, Apr 18, 2016 at 11:18 AM, Manuel Jacob <me at manueljacob.de>
> wrote:
> 
>> [This mail could be an answer to the other responses as well, as they
>> basically are the same.]
>> 
>> Ah, I think I understand now what poison is for.  Adds are defined to 
>> not
>> have side-effects, so the dependence rule is needed so the optimizer 
>> is
>> allowed to exploit undefined behavior.  Is this correct?
>> 
>> I forgot to mention in my original mail that our trapping arithmetic
>> operations are fully speculable.  This means that the trap won't 
>> happen
>> until the result is e.g. stored to memory.  A bit like poison values 
>> in
>> hardware.
>> 
>> Something is still unclear to me: while, according to the examples in
>> LangRef, a volatile store has undefined behavior when a poison value 
>> is
>> stored, this seems to not be true in case of non-volatile stores.  Can
>> someone clarify please?
>> 
>> 
>> On 2016-04-15 19:44, John Regehr via llvm-dev wrote:
>> 
>>> No, trapping is not allowed, since an overflowing add nsw is
defined
>>> to produce a poison value, which sort of explodes into undefined
>>> behavior if it reaches a side-effect.  This is to support
speculative
>>> execution.
>>> 
>>> If you emit trapping adds for nsw, you'll see spurious traps
every
>>> now
>>> and then.
>>> 
>>> There's a stronger form of undefined behavior, exhibited by
things
>>> like divide by zero, that permits traps.
>>> 
>>> John
>>> 
>>> 
>>> 
>>> On 4/15/16 7:28 PM, Manuel Jacob via llvm-dev wrote:
>>> 
>>>> Hi,
>>>> 
>>>> In our backend, we currently emit add operations that trap on 
>>>> overflow
>>>> if the IR operation has the nsw flag set.  Is this allowed?
>>>> 
>>>> According to the documentation about poison values, overflowing
a
>>>> nsw
>>>> add is undefined behavior.  However I didn't find a formal 
>>>> definition of
>>>> undefined behavior in LLVM.  Judging from previous discussions
on
>>>> the
>>>> mailing list, there seems to be a vague line of what LLVM is
allowed
>>>> to
>>>> do in case of undefined behavior.  Is trapping allowed?
>>>> 
>>>> -Manuel
>>>> 
>>>