This is the mail archive of the
mailing list for the GCC project.
Re: What to do with new-ra for GCC 4.0
On Tue, 2005-01-04 at 15:59 +0100, Bernd Schmidt wrote:
> >>and its core algorithm is comprehensible enough
> > I disagree ;-)
> Take away all the crufty layers of superfluous bits, such as the
> inheritance code, and you'll end up with a core that is actually quite
> small and elegant.
> If new-ra has failed, maybe I should resurrect my old attempt at
> rewriting the uglier parts of reload. A couple of years ago I had
> patches which tried to address two problems I see with the current code:
> * reload insn ordering is done with a bizarre set of reload_types
> * pieces of reload inheritance are scattered everywhere, which
> doesn't help make it maintainable.
> What I did was to detect dependencies between reload insns and create an
> ordering with a mini-scheduler. All information about reloads and
> reload insns is kept around while processing the insns, and inheritance
> is performed as an additional pass over this information. Inheritance
> becomes a localized pass instead of bits of code strewn across multiple
> files, and since it has more global information to work with, it can
> make better choices (in theory, anyway).
> The code isn't in a usable state right now, and since it has the
> downside of increased compile times and memory usage, I'm not sure
> anymore it's a feasible approach. If anyone else is interested, maybe
> I'll resurrect it and put it on a branch.
If reload is going to hang around (and I suspect it will), I'd love to
see those two areas improved. I can't express how difficult I find
it to analyze the reload inheritance code. Reload ordering is only
mildly easier to understand.