Re: new register allocator and HARD_REGNO_CALL_PART_CLOBBERED

[Joern Rennecke <joern dot rennecke at superh dot com>]

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.

> >> 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.

> 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.

> 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.  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.
	
-- 
--------------------------
SuperH (UK) Ltd.
2410 Aztec West / Almondsbury / BRISTOL / BS32 4QX
T:+44 1454 465658