[PATCH] Fixing inst-combine not to drops nsw when combining adds into mul (PR19263)

Rafael EspĂ­ndola rafael.espindola at gmail.com
Thu Jun 5 12:26:25 PDT 2014


On 5 June 2014 14:35, Dinesh Dwivedi <dinesh.d at samsung.com> wrote:
> Yes, now WillNotOverflowSignedAdd can handle cases where
> one of LHS and RHS is power of 2 and other has known zero
> after high bit in first one. I will update test accordingly or if you
> think that should go as independent patch I can surely do that.

An independent patch is probably better, as it makes it easier to review.

> For you other comment, I think we can not have nsw in addition
> of 2 variables even if any one of them is not known to have nsw.
> So I think nsw in add is wrong. But I may be wrong.
>
> How about this input
> a = 0x2aaa
> b = 0x5554
> c = 0x7ffe
> d = 0xd552
>
> b and c are ok here as mul instructions does not guaranty either
> (overflow and no overflow) but add instruction guaranties no sign
> overflow but d is overflowing.

Having nsw means that the addition will produce a poison value if
there is a signed overflow. So in the original code

define i16 @f(i16 %a) {
       %b = mul i16 %a, 2
       %c = mul i16 %a, 3
       %d = add nsw i16 %b, %c
       ret i16 %d
}

No poison value is produce for "a = 0x2aab", and as you noticed, a
poison value is produced for  "a = 0x2aaa".

For the transformation to be valid, it must never introduce a poison
value where there was none before. The above function might have been
used in a context where 'a' happens to never be 0x2aaa (or other
poison creating value), but could be 0x2aab.

Cheers,
Rafael



More information about the llvm-commits mailing list