new register allocator and HARD_REGNO_CALL_PART_CLOBBERED

[Daniel Berlin]

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.
>> So if we need an integer register we can use r4 during a call. If we 
>> need
>> a floating point register we can not use r4 during a call.
>
> Daniel Berlin:
>> Uggh.
>> That's horrific.
>> You aren't going to be able to get this to happen in a reasonable way.
>> Ideally, the regclass pass should be handing us a register class 
>> that's actually valid here. It's not. Reload should also be fixing 
>> the new-ra's mistake (which isn't really it's fault). It doesn't.
>> Either would be better than hacking the new-ra to handle these 
>> oddities, and the first would result in faster and better allocation.
>>
>> If you really want me to give you a patch to fix this in new-ra, i 
>> will, but i *really* don't think it's the right place.
>
> regclass is not supposed to know about lifetimes, and you need to know 
> if and
> how often the lifetimes of a pseudo cross a conflicting call, and what 
> the
> register pressure on sufficiently call-saved registers are there to do 
> this
> right.  So it is the job of the register allocator.

Then regclass is worthless, to be honest.
It hands us register classes containing invalid registers for a pseudo.
We can't rely on it to give us a set of registers that are usable for 
the register.
For the invalid registers it gives you, one doesn't know how much 
better or worse any other set of registers is.
So remind me again why it's helpful?

I'll note that this is one of the reasons it's replaced with the 
web_class stuff (in combination with pre-reload) on new-regalloc-branch.

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

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


> The SH5 has it too,
Embedded platforms are the most prolific producers of weird register 
constraints.

--Dan