[LLVMdev] On semantics of add instruction - nsw,nuw flags

[Tobias Grosser]

On 23/07/2014 20:32, Dan Gohman wrote:
>
>
>
> On Wed, Jul 23, 2014 at 1:54 AM, Tobias Grosser <tobias at grosser.es
> <mailto:tobias at grosser.es>> wrote:
>
>     On 23/07/2014 09:46, Tim Northover wrote:
>
>             Then why does the Release Note say
>             " the operation is guaranteed to not overflow".
>
>
>         It means that the person who wrote the IR has guaranteed that
>         there's
>         no overflow (by some means) so LLVM can assume it during
>         optimisation.
>
>         This guarantee might come from doing explicit checks before
>         executing
>         the add/sub; or perhaps from performing the operation after a
>         sext so
>         that the type is guaranteed to be big enough; or (as in C) by
>         trusting
>         the programmer to make sure that doesn't happen.
>
>             What are the redundancies in the following code snip. Assume
>             they appear in
>             that order in a basic block.
>
>                 Case1; %add2 = add nsw i32 %add, %add1
>                            %add3 = add        i32 %add, %add1
>
>                 Case2: %add2 = add        i32 %add, %add1
>                            %add3 = add nsw i32 %add, %add1
>
>
>         In both cases the add with nsw can be removed in favour of the one
>         without. Order is completely irrelevant for normal LLVM arithmetic
>         instructions.
>
>
>     Tim,
>
>     if both instructions are right after each other such that we know
>     that either none of them or both will be executed, is there a way to
>     leave the nsw flag taking advantage of the knowledge that any pair
>     of values
>     that cause nsw in the instruction that originally had now nsw flag
>     is already known to break the nsw assumption of the other instruction
>     and causes consequently undefined behaviour?
>
>
> No; the motivation for poison values (formerly named trap values, if
> anyone is reading the rationale linked to earlier in the thread) is to
> defer undefined behavior until execution can no longer be speculative.
> The location where a poison value is produced isn't significant. What's
> important is the location of the use of a poison value (and how it's used).
>
>
>     The langref description is a little surprising, as it seems the
>     undefined behaviour only is invoked is the resulting poison value is
>     actually used:
>
>     "Poison Values have the same behavior as undef values, with the
>     additional affect that any instruction which has a dependence on a
>     poison value has undefined behavior."
>
>
> Correct. nsw isn't a guarantee that overflow won't occur. It is
> (intended to be) a guarantee that if overflow does occur, the program
> will avoid using the result for anything important (roughly speaking).

Thanks, for bringing this back to my mind.

Tobias