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

[David Majnemer via llvm-dev]

On Mon, Apr 18, 2016 at 12:48 PM, Manuel Jacob <me at manueljacob.de> wrote:

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


No because that would result in reg2mem introducing traps where none
existed before.


>
>
> 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/31b6215c/attachment.html>