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

Eric Christopher echristo at apple.com
Fri Mar 4 00:29:12 PST 2011


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.

I'm uncertain what a more modern gcc does in the case that they actually want to do something with the overflow flag.

-eric





More information about the llvm-commits mailing list