Re: What to do with new-ra for GCC 4.0

[bernds_cb1 at t-online dot de (Bernd Schmidt)]

Jeffrey A Law wrote:
> On Tue, 2005-01-04 at 15:59 +0100, Bernd Schmidt wrote:
> > 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.

I'm attaching a proof-of-concept patch, against a checkout from 
20050106.  The main things this patch does
 * replace reload insn ordering using RELOAD_FOR_blah by dependencies
   automatically generated from the replacements
 * replace reload inheritance by a separate pass that is run on data
   collected by find_reloads
 * try to make inheritance powerful enough that many other random
   optimizations scattered across reload can be deleted (I hope that
   eventually, reload_cse_regs can go as well)

The changes in genoutput.c are necessary to deal with the fact that some 
machine descriptions have output operands without a "=" constraint letter.

Todo items:
 * This patch is from pre-GC times, so some of its memory management
   decisions aren't very clever anymore.  No RTL on obstacks :-(
 * Doesn't handle inc_for_reload very gracefully
 * Not too stable yet

It compiles (tested on i686-linux) and holds up pretty well for the 
testsuite, but it does not bootstrap yet.

Any comments welcome.  Does this look like something we want to pursue?


Bernd

Attachment: rld-050114.diff.bz2
Description: BZip2 compressed data