This is the mail archive of the
mailing list for the GCC project.
Re: Register allocation problem?
- To: Daniel Berlin <dan at cgsoftware dot com>
- Subject: Re: Register allocation problem?
- From: Peter Bergner <bergner at brule dot borg dot umn dot edu>
- Date: Tue, 21 Aug 2001 11:53:18 -0500
- Cc: Lars Brinkhoff <lars at nocrew dot org>, gcc at gcc dot gnu dot org
- References: <email@example.com> <firstname.lastname@example.org>
Daniel Berlin wrote:
: It coalesces both regs to the same hard reg (It actually knows the
: moves become noops, but because we still have reload, and it does
: weird things at times, we don't flat out delete the noop moves we
: create, since they'll get removed post reload anyway.)
Why is it again we run reload after the new allocator (I assume this
conversation occurred before I rejoined the mailing list)?
As a cautionary note, I'll add that we might want to be careful
coalescing pseudos with hard regs, particularly if the pseudo
has a small spill cost yet has a large live range. Once it's
coalesced to a hard reg, that hard reg is off limits to other
possibly more important pseudos.
Talking with Preston Briggs back when I was still in school,
he mentioned that the Rice compiler slightly cripples the
coalescing phase during the 1st iteration through the reg-alloc
loop to not allow coalescing of pseudos and hard regs. Then in
all subsequent iterations, they allow unrestricted coalescing
between pseudos and hard regs. The assumption was that most
spilling occurs in the first iteration, so coalescing to hard
regs after the first iteration shouldn't add too much spill code.
However, as Lars' case shows, coalescing pseudos to hard regs
has benefits. Preston solved this by _always_ running at least
2 iterations of the reg-alloc, even if no spilling was required
in the first iteration.
I'm not saying this is a good solution, just the way Preston
solved it... and working on a research compiler, your main
focus is on performance of the generated code, not the compiler
itself. :-) I don't remember what I did and I'm a little too
lazy to go hunting through the code, but I probably just allowed
the coalescing of pseudos and hard regs. It was to my benefit
if the base register allocator produced a lot of spill code! :-)
SLIC Optimizing Translator Development / Linux PPC64 Kernel Development
IBM Rochester, MN
bergner AT us DOT ibm DOT com