[LLVMdev] The nsw story
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