Re: hard register reload patch

[Joern Rennecke <amylaar at cygnus dot co dot uk>]

> Don't we usually write this loop using a "while" so that we strip off any
> nested SUBREGs?

We use a "while" when we also strip STRICT_LOW_PARTs / ZERO_EXTRACTs /
SIGN_EXTRACTs .  We don't expect these in a call insn, so we don't handle
them here.  SUBREGs are not supposed to be nested.

>   > +   regno = REGNO (reg) + word;
>   > +   endregno = regno + HARD_REGNO_NREGS (regno, mode);
> Is "mode" really correct here?  You're going to get the mode of the outer
> SUBREG.  I have no idea if that's what you wanted or not.

It is what I wanted.

> I didn't see what ChangeLog entry corresponded to pulling that code out
> of the loop itself [ I'm glad you pulled that code out of the loop; I have
> no idea why I wrote the code in that manner in the first place. ]

It is this one:
        (insert_restore, insert_save): Add restored / saved registers to
        dead_or_set.
I had to insert the insert_one_insn call before the loop over the hard
registers, so I had the choice between putting more non-looping code
into the loop or pulling some out.

> In insert_one_insn, do you need to update the REG_DEAD notes, or does reload
> not care about them?
> 
> It also seems to me that you got the live_throughout wrong.  The register
> dies at the save insn, right?  Then why set new->live_throughout.  I think
> we've got the mirror case to consider at the restore.  [ I'm talking about
> the code in insert_one_insn still. ]

The register might continue to be live till the call_insn, if it is used
as a function argument.  We could test for that, but that would be another
optimization that we don't currently do.  Likewise for adding REG_DEAD notes.

> In reg_becomes_live, when setting regs_set you special cased fixed registers
> when the original register was a hard register, but not when the original was
> a pseudo, why?  Similarly in reg_dies.

We don't allocate pseudos to fixed registers.

> Have you bootstrapped with this change?  Have you done any timing tests to
> see if reload/global allocation is faster?

I have bootstrapped with this change, but I haven't run any timing tests.