[llvm-dev] Is trapping allowed when an add with nsw flag overflows?

[Manuel Jacob via llvm-dev]

[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