What to do with new-ra for GCC 4.0

[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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rld-050114.diff.bz2
Type: application/x-bzip2
Size: 90921 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20050114/8532ba43/attachment.bz2>