llvm dev - Jul 2014 - [LLVMdev] On semantics of add instruction - nsw,nuw flags

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

Cheers.

Tim.

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?

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."

Cheers,
Tobias

Hi Tim,
If:
>  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.
>>
> then
>  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.
>>
>
> why can't we retain *add nsw* and remove *add *(in the example Cases)?
Because there is a guarantee overflow wouldn't occur.

Thanks,
-- 
Rekha
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/dcce858e/attachment.html>

On Wed, Jul 23, 2014 at 1:54 AM, Tobias Grosser <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).

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/2cb7a786/attachment.html>