llvm dev - Dec 2011 - [LLVMdev] The nsw story

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?

Dan

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.

-Chris

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