[LLVMdev] The nsw story

[Dan Gohman]

On Dec 1, 2011, at 9:09 AM, Chris Lattner wrote:

> 
> On Dec 1, 2011, at 8:46 AM, Dan Gohman wrote:
> 
>> 
>> On Nov 30, 2011, at 10:49 PM, Chris Lattner wrote:
>> 
>>> 
>>> On Nov 29, 2011, at 3:21 PM, Dan Gohman wrote:
>>> 
>>>> 
>>>> A natural reaction to this problem is to think that LLVM IR is so nice
>>>> and pretty that naturally there must be a nice and pretty solution. Here
>>>> are some alternatives that have been considered:
>>>> 
>>>> - Go back to using undef for overflow. There were no known real-world
>>>> bugs with this. It's just inconsistent.
>>> 
>>> +1 for the simple and obvious answer.
>> 
>> To be clear, the main sign-extension elimination optimization is not valid under
>> the simple and obvious answer.  Are you proposing to do it anyway?
> 
> Please define "valid".  We discussed this a very very long time ago, and I don't recall the details.


int a = INT_MAX, b = 1;
long c = (long)(a + b);

What is the value of c, on an LP64 target?

By standard C rules, the add overflow invokes immediate undefined behavior of course.

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
  0x0000000000000001
  0x0000000000000002
  ...
  0x000000007fffffff
or
  0xffffffff80000000
  0xffffffff80000001
  0xffffffff80000002
  ...
  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.

Therefore, if signed add overflow returns undef, promoting such 32-bit variables to
64-bit variables is not a behavior-preserving transformation.

Dan