[LLVMdev] The nsw story

[Chris Lattner]

On Dec 5, 2011, at 7:44 PM, Dan Gohman wrote:

> 
> On Dec 5, 2011, at 5:50 PM, me22 wrote:
> 
>> On Thu, Dec 1, 2011 at 09:23, Dan Gohman <gohman at apple.com> wrote:
>>> 
>>> int a = INT_MAX, b = 1;
>>> long c = (long)(a + b);
>>> 
>>> What is the value of c, on an LP64 target?
>>> 
>>> If a and b are promoted to 64-bit, c is 0x0000000080000000.
>>> 
>>> In a world where signed add overflow returns undef, c could be any of
>>> 0x0000000000000000
>>> ...
>>> 0xffffffffffffffff
>>> however it can't ever be 0x0000000080000000, because there's no 32-bit value
>>> the undef could take which sign-extends into that 64-bit value.
>>> 
>> 
>> But since the add nsw returns undef, then isn't c "sext i32 undef to
>> i64", and thus also undef?
> 
> No; sext i32 undef to i64 returns an extraordinary thing. It's a
> 64-bit value where the low 32 bits are undef, and the high
> 32 bits are sign extension from whatever bit 31 happened to be.

More precisely, the high 33 bits are known to be the same.

> operands and opcodes. It's quite magical.

It's actually not that magical.  It's also essential that we have this behavior, otherwise normal bitfield code has "undefined" behavior and is misoptimized.  This is why the result of "undef & 1" is known to have high bits zero.

-Chris