Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 13 May 2003, Joern Rennecke wrote:

> Daniel Berlin wrote:
> >
> > On Tuesday, May 13, 2003, at 06:27  AM, Joern Rennecke wrote:
> >
> > > Herman ten Brugge:
> > >> For example the c4x target will only save the integer part of
> > >> register r4.
> > Then regclass is worthless, to be honest.
> > It hands us register classes containing invalid registers for a pseudo.
>
> They are not invalid.  It's just that you would need to use caller
> saves to use them.  That's just the same with ordinary call-used /
> call-clobbered registers.

No, they are invalid. It frequently gives us regs we can't use *at all*
(IE regardless of call status, they just aren't even okay for the
mode at all).

 >
> > >> It's not difficult, it's just exactly the kind of extra-special port
> > >> specific
> > > stuff we don't want new-regalloc to be directly handling if it can
> > > avoid it.
> > >
> > > It's not all that special.
> >
> > Actually, it is.
> >
> > These are hard regs that can have either an integer or floating point
> > value in them (which isn't typical of our main platforms), but are only
> > partially clobbered if they contain integer values.
>
> No, that is an overgeneralization.  On other platforms, you have registers
> where genuinely just a part is saved, i.e. on the SH5, only 32 bits of
> the registers used by SHcompact are saved, but the register might be used
> for 64 bit values in SHmedia code, as long as you don't use them across
> calls without saving/restoring them around these calls.

I was talking about the specifics of the c4x requirements here, which are
as I stated.

>
> > This is untypical of our main platforms, thus, "special".
> > It may be common in embedded platforms, it would not surprise me.
> > However, in order for the new-register allocator to make a good
> > decision here, it needs to know what registers would be usable ahead of
> > actual allocation time (as opposed to just throwing out regs it thought
> > it could use when it comes time to get a free register), so it can
> > accurately estimate costs, and model conflicts.  In turn, this affects
> > coalescing and actual allocation.
>
> You can do this ahead of time, by looking at the modes of the pseudos
> you want to allocate in the register.

Which is what i suggested, rather than putting it in get_free_reg.
The portion of code we have now that looks at the modes is regclass.
So i suggested it goes there.

>
> > The actual allocator is *not* the right place to do this pruning,
> > although it may go into one of the ra*.c files, which consist of more
> > than just the actual allocator i was referring to.
> > Herman wanted to do this in get_free_reg, which, for the reasons i just
> > pointed out, is exactly *not* where it belongs.
>
> If you put it into another part of the register allocator, that's fine
> too.
As I mentioned, i was referring to the allocator as the graph coloring
portion, not the dataflow stuff done at the beginning.
>  I just wanted to point out that this is a job for the register
> allocator, not, for example, reload - reload should only fix up cases
> where you use a register that doesn't work in a particular instruction,
> it is not supposed to magically solve problems with persistency of
> values beyond the scope of a single instructions and its reloads.
I didn't claim it should be in reload, that's clearly the wrong place too.

>
> --
> --------------------------
> SuperH (UK) Ltd.
> 2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
> T:+44 1454 465658
>