This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Preliminary results on new register allocator
- To: <gcc at gcc dot gnu dot org>
- Subject: Preliminary results on new register allocator
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: Wed, 24 Jan 2001 13:41:34 -0500 (EST)
Okay, the new register allocator is basically done.
Or at least, done enough to allocate registers properly for a given class
of registers.
(I still have to add the code to handle registers that can are in multiple
classes, etc. Not that difficult, or adding much complexity. Also have to
do some tuning.)
This is on some random code on a powerpc that only uses integer registers.
regmove ->local alloc->global alloc->reload
--------------------------------------------
regmove - removed a few moves
local-alloc - wanted to spill just about everything
global alloc - same
reload - put things back into registers, used 15 registers totally.
vs
new allocator
-------------
removed same moves as regmove, used 15 registers total.
r->l->g->r
----------
regmove - removed a few moves
local-alloc - wanted to spill for 5 insns
global-alloc - same
reload - put them back into registers, used 3 registers total
vs
new allocator
-------------
removed same moves as regmove, used 3 registers total.
In short, it looks, at least on random test code i have run it on (I just
finished the it about 15 minutes ago, so i've only started
running tests), on my ppc, it does as well as those 4 passes combined.
It's currently 1147 lines of code, with 25% of the code being used for my
hashed set implementation (I'm pretty sure you could use sbitmaps for
almost all of the stuff i use hashed sets for, but i couldn't quite wrap
my head around all the transformations and whatnot needed).
Just some prelim statistics, figured i'd let you all know.
--Dan