Re: Register allocation cost question

[Andrew Stubbs <ams@codesourcery.com>]

On 10/10/2023 20:09, Segher Boessenkool wrote:
> Hi Andrew,
> 
> On Tue, Oct 10, 2023 at 04:11:18PM +0100, Andrew Stubbs wrote:
>> I'm also seeing wrong-code bugs when I allow more than 32 new registers,
>> but that might be an unrelated problem. Or the allocation is broken? I'm
>> still analyzing this.
> 
> It could be connected.  both things should not happen.
> 
>> If it matters, ... the new registers can't be used for general purposes,
> 
> What does this mean?  I think you mean they *can* be used for anything,
> you just don't want to (maybe it is slow)?  If you make it allocatable
> registers, they *will* be allocated for anythin the compilers deems a
> good idea.

Nope, the "Accelerator VGPR" registers are exclusively for the use of 
the new matrix multiply instructions that we don't support (yet).

The compiler is free to use them for storing data, but there are no real 
instructions to do there.

>> so I'm trying to set them up as a temporary spill destination. This
>> means they're typically not busy. It feels like it shouldn't be this
>> hard... :(
> 
> So what did you do, put them later in the allocation order?  Make their
> register_move_cost higher than for normal registers (but still below
> memory_move_cost)?  Or what?  TARGEt_SPILL_CLASS maybe?

We put them in a new register class, with a new constraint, and 
implemented the move instructions (only) with new alternatives for the 
new class. Then implemented TARGET_SPILL_CLASS in the obvious way.

All this is working just fine as long as there are only 32 new registers 
unfixed (a0-a31); the code even runs correctly and I can see the 
spilling happening correctly.

If I enable register a32 then it prefers that, and I get wrong code. 
Using that register ought to be logically correct, albeit suboptimal, so 
I don't understand that either.

Andrew