[llvm-commits] [llvm] r98023 - /llvm/trunk/lib/CodeGen/SimpleRegisterCoalescing.cpp

Jakob Stoklund Olesen stoklund at 2pi.dk
Tue Mar 9 09:41:10 PST 2010


On Mar 8, 2010, at 5:37 PM, Jakob Stoklund Olesen wrote:

> 
> On Mar 8, 2010, at 5:23 PM, Evan Cheng wrote:
> 
>> Is 1000 scientific? :-)
> 
> No. That would require measuring when the LiveInterval size where it outgrows cache. I didn't do that :-(
> 
> I have also seen cases where a virtual register LiveInterval becomes too big. That is a lot harder to fix. I think the real problem is the extra indirection in SlotIndex. If SlotIndex were just an unsigned in disguise, each LiveRange would be just 16 bytes, and all ranges for a register would be in contiguous memory. 

OK, I did the science now ;-)

I was wrong.

I disabled the inliner and compiled this function with varying array lengths:

#include <utility>
typedef std::pair<int,int> P;
P f(int n) {
    static const P t[] = {
        P(84, 89),
        P(39, 44),
        P(79, 84),
        P(80, 85),
        P(92, 97),
        P(19, 24),
        P(33, 38),
        P(77, 82),
        P(28, 33),
        P(55, 60),
    };
    return t[n];
}

It produces lots of constructor calls like this:

	leaq	__ZZ1fiE1t+184(%rip), %rdi
	leaq	-196(%rbp), %rsi
	leaq	-200(%rbp), %rdx
	callq	__ZNSt4pairIiiEC1ERKiS2_

The coalescer timing formed a perfect parabola with t=4.1s at N=2000. This is not a caching effect - the coalescer is quadratic in the number of function calls!






More information about the llvm-commits mailing list