Displaying 3 results from an estimated 3 matches for "significantlty".
2007 Jun 22
0
[LLVMdev] BigBlock register allocator
...earscan. So if you're compiling very large,
> (probably) machine-generated blocks of straight-line code, give the
> Local and BigBlock allocators a try, especially if you're JITing
> things and compile time is important.
I looked at your code. And I see some things that could be
significantlty sped up, e.g.
- InsnTimes handling. I have the feeling, this map can be eliminated
completely.
- use of the VRegReadTable. The vector of read occurences can be
shortened every time, you processed the corresponding intruction. This
makes it shorter and makes searches inside this vector faster, thu...
2007 Jun 22
3
[LLVMdev] BigBlock register allocator
Hi everyone,
Quick summary:
LLVM now has a new register allocator particularly suitable for
compiling (very) large, machine-generated functions.
Longer story:
I've recently been using LLVM in an application that involves JITing
fairly large functions that have no control flow - they're just flat
sequences of instructions, anywhere from 100 to 10000+ in size. (The
control flow is
2007 Jun 22
1
[LLVMdev] BigBlock register allocator
...allocator. Using bigblock gives another
10~20% on top of that, with the gap more or less proportional to the size
of the block. For blocks with <200 instructions, local and bigblock tend
to produce more or less the same code.
> I looked at your code. And I see some things that could be
> significantlty sped up, e.g.
> - InsnTimes handling. I have the feeling, this map can be eliminated
> completely.
Absolutely, I agree it should go. I was in a hurry, and my first attempt
at eliminating it didn't work, so I just put it back. I'll get around to
killing it again at some point.
>...