Re: Reload work in progress

[Bernd Schmidt <bernds at redhat dot co dot uk>]

On Wed, 13 Sep 2000, Jeffrey A Law wrote:

> 
>   In message <Pine.LNX.4.21.0008231816250.9300-100000@balti.cygnus.co.uk>you wr
> ite:
>   > Every now and then, I'm working on a patch that changes several aspects of
>   > how reload works.  So far, most of the discussion has been on Redhat
>   > internal mailing lists; Jeff asked me to post a message here as well so
>   > that people know about it.  I'm not appending the patch in this mail, it's
>   > a bit too large (600K uncompressed).  If anyone is interested, I can send
>   > it privately - it's against a not too old CVS version of gcc.
> So, one of my questions is are there pieces we can start reviewing and
> installing?

That's rather difficult.  I can't think of a sane way to do that right now.
I can see three steps of breaking it up:
1. Remove old cruft
2. Make a minimal conversion to the new system (probably still a large patch)
3. Add optimizations (the new inheritance pass)

We could only do this on a branch, since temporarily removing the current
inheritance code will have a negative effect on code quality.

>   > The patch tries to address what I perceive are several flaws of reload:
>   >  - The enum reload_type/reload_when_needed handling, which tracks reload
>   >    lifetimes (such as RELOAD_FOR_INPUT, etc.).
>   >    From the original reload implementation, which didn't even have this, to
>   >    the current one, this has grown enormously.  One of the problems with it
>   >    is that it doesn't give us exact lifetimes of reload registers, and a 
>   >    lot of effort must be invested to get any useful life information out
>   >    of it at all.  For example, there's a 100 line kludge near the end of
>   >    find_reloads which has to modify some combinations of reload types
>   >    because the code in reload1.c is incorrect and doesn't handle all
>   >    possible cases properly.
> Presumably the basic concept you're going to use to replace this involves
> creating some kind of dependency tree for the reloads?

Yes.  Strictly speaking it's not a tree, and it involves not only reloads,
but also the main reloaded insn and its input & output registers.

> Can't argue with the fact that inheritance is an unmaintainable mess with
> its current implementation.  However, I'll withhold opinions about the
> cleanup passes -- it'd be nice to zap them and we may be able to do so
> if your code works out as well as we'd like -- let's consider wiping the
> cleanup passes one of the goals, but not a requirement for this work.

OK.

>   >      There can be three ways a register is used: either it's a reload
>   >      register, it's used as an input, or it's used as an output.  By keepin
>   >      keeping track of registers explicitly used in the insn (either as hard
>   >      regs or as allocated pseudos), we can figure out exactly which regs
>   >      conflict with each reload.  This might in a few cases lead to better
> So for my own information, how would something like an output address reload
> be classified in your scheme?  It has some properties of an input reload
> and others of an output reload.

It's never written to by the insn, so it's clearly an input.  The only
relation it has to an output is that it could possibly be done after the
main insn.

> What about secondary reloads?

I haven't completely decided how I want to handle them.  At the moment,
they aren't represented in the d/u chains; once all the lifetimes for
primary reloads are calculated, the lifetimes of secondary reloads are
set identical to those of their primaries.  An alternative strategy
would be to model them as additional links in the dependency chains.
However, there's likely to be little reason to schedule them away from
their primary reloads.


Bernd