Register allocation trouble

Andrew Stubbs andrew_stubbs@mentor.com
Fri Jul 21 13:14:00 GMT 2017


Hi all,

I have an architecture that has two register files. Let's call them 
class A and class B. There are some differences between their 
capabilities, but for the purposes of this problem, they can be 
considered to be identical, both holding SImode values, and both able to 
receive values without a secondary reload.

In order to load data into A, the address register must also be in A. 
Similarly, in order to load data into B, the address register must also 
be in B.

So I set up my (simplified) pattern:

(set (match_operand:SI "register_operand" "=a,b")
      (match_operand:SI "memory_operand"   "Ra,Rb"))

where
   "a" is a register in A
   "b" is a register in B
   "Ra" is a mem with base address in A
   "Rb" is a mem with base address in B

(Obviously, there are stores and moves and whatnot too, but you get the 
idea.)

The problem is that the register allocator cannot see inside Ra and Rb 
to know that it must allocate the base register correctly. It only knows 
that, some of the time, the instruction "does not satisfy its constraints".

I believe the register allocator relies on base_reg_class to choose a 
class for the base register, but that just says "AB" (the union of class 
A and class B), because it has no context to say otherwise. Only the 
constraints define what hard registers are acceptable, and all they see 
is pseudoregs during reload.

Similarly for the other hooks I've investigated: they don't have enough 
context to know what's going on, and the rtx given always has pseudo 
registers anyway.

The only solutions I can think of are to either preallocate the loads to 
register classes via some means MODE_CODE_BASE_REG_CLASS can see 
(address spaces, perhaps), or to have an alternative that catches the 
mismatching cases and splits to a load and move, or set the base class 
to A and always load via secondary reload for B.

Any suggestions would be greatly appreciated.

Andrew



More information about the Gcc mailing list