Re: hard register reload patch

[Bernd Schmidt <bernds at pathia dot cygnus dot co dot uk>]

On Tue, 30 Nov 1999, Jeffrey A Law wrote:

>  In message <Pine.LNX.4.10.9911301449040.895-100000@darkstar.frop.org>you writ
> e:
>   > I suggest we keep the rules simple and easy to understand: the only insns
>   > which reference hard registers may be moves which copy them into/out of
>   > pseudos.  Hard registers may not live across any other insns.
>   > To me, this appears to be what was originally intended, but it's not how 
> all
>   > parts of the compiler behave these days.  [I have an unreviewed combiner
>   > patch (~ 10 months old) which tries to replace the (convoluted) logic
>   > dealing with hard regs and SMALL_REGISTER_CLASSES with code that just
>   >  enforces these
> I remember that patch.  And I still think that particular issue is better
> solved by improving the LOG_LINKS that we generate.  Ultimately what we need to
> do is prevent pseudos which must be assigned to the same hard register from
> having overlapping lifetimes.

That is a different issue.  The combiner problem I had caused an explicit
hard register reference to %ecx to be substituted into a shift insn with
variable count (and variations on that theme), causing a spill failure later.

> We can do that either via a series of hacks based on SMALL_REGISTER_CLASSES,
> which is rather lame.  First, SMALL_REGISTER_CLASSES as a whole is a hack.
> Second, there are targets which tend to have plenty of hard registers is
> most classes, but may have one or two classes with a limited number of
> registers.  Third, it just doesn't seem right.

Why don't we apply the same rules across all machines?  What is the benefit
that non-S_R_C machines have from potentially longer hard register lifetimes?
(note that we can exclude fixed/global regs from these considerations and
treat them like pseudos, since the register allocators can't use them
anyway).

(I have to admit that at the moment I can't really imagine what your proposed
solution to change LOG_LINKS generation would look like).

>   > It's a start to fix one of the remaining problems that make reload the mess
>   > that it is today: reload registers are allocated both in reload1.c
>   > (choose_reload_regs, find_reload_regs, and all the rest) and in reload.c
>   > (all the places that set reload_reg_rtx).  The latter know about the fact
>   > that certain hard regs live only through parts of the insn and make
>   > decisions based on that knowledge, while the former ignore this issue.
>   > It would be nice to have only one place in reload that allocates reload
>   > registers.  Joerns patch is a step in that direction (combine_reloads goes
>   > away).
> How related is this to your reload cleanup patch.  It sounds like the same
> thing, and I've already agreed that we're going in the right direction.

Not exactly the same thing.  My cleanup patch just tries to unify the two
allocators in reload1.c to some extent, but doesn't do anything yet about
tracking lifetimes of hard registers properly in that code.

> I'm tempted to start with your cleanup patch first simply because it does
> make parts of reload less fragile and easier to understand.  It also seems
> like is fairly close to being ready to integrate.

I think the only thing that remains is to decide what to do about the
inv_reg_alloc_order thing.  We could sidestep the issue what to do about
ports that don't define REG_ALLOC_ORDER for now and just add
inv_reg_alloc_order if R_A_O is defined.  Then keep the ifdefs (for now).
How does that sound?

> Probably the next one would
> be Joern's code to improve live_before/live_after stuff.  Then carve out the
> next useful concept.

Yup.  Sounds sensible to me.

Bernd