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

[Rekha R]

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.

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/73dc544f/attachment.html>