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

[Jeremy Lakeman]

On Wed, Jul 23, 2014 at 4:06 PM, Rekha R <rekharamapai at nitc.ac.in> wrote:

> Ok. Got it.
>
> If *add nsw* overflows, this results in undefined value.
> But then *add* on same arguments results in well-defined value.
>
> Hence treating first one as redundant based on the second is acceptable.
> But vice versa is not.
>

If they are in different code paths, sure. It's not an undefined value,
it's undefined *behaviour*. We can assume that the operation might crash,
so the rest of the block is unreachable.
What you're really saying to the compiler with the nsw flag is " that the
operation is *guaranteed *to not overflow" (
http://llvm.org/releases/2.6/docs/ReleaseNotes.html)
And that the compiler can use this information in optimising the rest of
your code.


>
> I was wondering on the role played by flags in detecting redundancies. At
> first I thought one need to consider only operands and operators. Now I
> understand flags also play a role.
>
> Thanks,
>  Rekha
>
>
> On Wed, Jul 23, 2014 at 11:42 AM, Jeremy Lakeman <Jeremy.Lakeman at gmail.com
> > wrote:
>
>> IMHO;
>> On undefined behaviour we can do whatever we want. If the "add nsw"
>> overflows this would lead to undefined behaviour.
>> Therefore we can assume that "add", with the same arguments will not
>> overflow.
>>
>>
>> On Wed, Jul 23, 2014 at 3:32 PM, Tim Northover <t.p.northover at gmail.com>
>> wrote:
>>
>>> On 23 July 2014 06:25, Rekha R <rekharamapai at nitc.ac.in> wrote:
>>> > Are the following instructions semantically same?
>>> >   %add2 = add nsw i32 %add, %add1
>>> >   %add3 = add        i32 %add, %add1
>>> >
>>> > Based on my understanding from the Language Reference Manual, I think
>>> they
>>> > are different. But then why is the gvn pass detecting %add3 as
>>> redundant and deleting it?
>>>
>>> On their common domain, the two instructions coincide. But the second
>>> one is defined for more pairs of input. That is, it's also defined
>>> when the (signed) sum overflows.
>>>
>>> So it's correct to eliminate the first one as redundant, in favour of
>>> the second, but not the reverse. This is what I see GVN doing too from
>>> my simple tests, do you have a complete .ll file where the wrong one
>>> is removed?
>>>
>>> Cheers.
>>>
>>> Tim.
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>
>>
>
>
> --
> Rekha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140723/77f0b227/attachment.html>