[LLVMdev] The nsw story

Dan Gohman gohman at apple.com
Thu Dec 1 09:23:58 PST 2011

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
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.


More information about the llvm-dev mailing list