[llvm-commits] [llvm] r126964 - in /llvm/trunk: lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp lib/CodeGen/SelectionDAG/LegalizeTypes.h test/CodeGen/X86/umulo-64.ll

[John McCall]

On Mar 4, 2011, at 12:29 AM, Eric Christopher wrote:
> On Mar 4, 2011, at 12:16 AM, Evan Cheng wrote:
>> On Mar 3, 2011, at 4:16 PM, Eric Christopher <echristo at apple.com> wrote:
>> 
>>> 
>>>> Err, I'm reasonably sure the code has precisely the same issues for
>>>> 64-bit... narrow my previous example and compile on x86-32, and you
>>>> end up with the following, which has the exact same issue:
>>> 
>>> So I was trying to be clever and have no idea what I was thinking. :)
>>> 
>>> Here's a simple patch that fixes the problem in something resembling correctness, but uses divide to do it - so yeah, performance?
>>> 
>> 
>> Math is hard.
> 
> Yep.
> 
>> But surely it's possible to generate better code. What do other compilers do?
> 
> Not sure what anything other than gcc does. For gcc they kind of avoid some of the problem we're trying to solve here. If -ftrapv is called they use a libcall that aborts if the multiply overflows. Otherwise they just use straight mul. This probably won't work for us because one of the big places that clang uses this built-in is to check whether or not an allocation overflows so that they can throw an exception for c++. And yes, I'd rather not have to split the block for every allocation just to make an "is this zero" check before doing a divide. Especially since it'd be always false in the normal case.

The allocation overflow checks are usually on x * C, in which case the unsigned overflow test should just be x >= ceil(2^w / C).  The general case is terrible, though.

John.