This is the mail archive of the
mailing list for the GCC project.
Re: What to do with new-ra for GCC 4.0
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: bernds_cb1 at t-online dot de
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 4 Jan 05 11:26:24 EST
- Subject: Re: What to do with new-ra for GCC 4.0
I can't say I've really looked at new-ra, but I'm wondering whether this
is a sane idea. Reload's purpose is to ensure that every instruction
matches its constraints, and its core algorithm is comprehensible enough
that you can know that it terminates and guarantees correct register
assignments. If it is moved before register allocation, what happens to
these guarantees? Or do you follow register allocation with another
pass of reload proper?
I've raised these issues as well and strongly agree with you that the original
purpose of reload (what you describe) is still needed. However, reload has
become immensely complicated lately with all the register tracking it does
among the reloads and in trying to reuse old reloads. This is indeed a
task more properly done by a register allocator and the fact that reload
will override the register allocator's work is also problematic.
However, how to do this in a more unified fashion is indeed a challenge.
Having the register allocator be responsible for all the spills and fills
might be a good thing, but basically means moving (or copying) a large chunk
of reload's code into the register allocator.