[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