[llvm-dev] Is trapping allowed when an add with nsw flag overflows?
Manuel Jacob via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 18 08:18:37 PDT 2016
[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
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
> 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.
> On 4/15/16 7:28 PM, Manuel Jacob via llvm-dev wrote:
>> 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
>> undefined behavior in LLVM. Judging from previous discussions on the
>> mailing list, there seems to be a vague line of what LLVM is allowed
>> do in case of undefined behavior. Is trapping allowed?
More information about the llvm-dev