[llvm-commits] PATCH: Preserving the 'nsw' flag in the instruction combiner.

[Nick Lewycky]

On 10 August 2011 12:37, Pranav Bhandarkar <pranavb at codeaurora.org> wrote:

> Hi Nick,
>
> >>Thanks for working on this! Firstly, I have a high-level question: why
> can't (X +nsw (C1 +nsw C2) always become (X +nsw C3)? Your patch spends a
> lot of time verifying that >>overflow couldn't occur, but you're given an
> assumption a priori that it can't because the nsw flag is present.
>
> The reason is that 127 (C1) + 2 (C2) = 129 (C3) is not strictly true
> always.
> For instance, when the type is i8, then C3 is -127.


127 + 2 = 129 remains true with i8 values, because i8 -127 = i8 129. They
have the same bit pattern.

Can you pick values for X, C1 and C2 which still satisfy the +nsw
relationship between each other that can't be converted into X +nsw C3 where
C3 = C1+C2 (no nsw requirement)? 127 and 2 don't work as counter-examples
because that triggers undefined behaviour (it violates the 'nsw' bit present
on the add).

Nick

Then we cannot guarantee
> the nsw flag for the values of x that we could before this combination (e.g
> x=-10). Adding the 'nsw' flag in this would mean that the semantics are not
> preserved in the strictest sense of the term. Does this address your
> question?
>


>>Sure it can overflow the unsigned wrap point (crossing between -1 to 0)
> but when merging two adds or two subs, does that ever matter?
>
> I do not think unsigned wrap matters.
>
> Thanks for your comments, I will incorporate your suggestions on the patch.
> Do let me know your thoughts on the reasoning above.
>
> Pranav
>
> Qualcomm Innovation Center, Inc is a member of Code Aurora Forum.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110810/40ac2528/attachment.html>