[LLVMdev] Adding address registers to back-end

Boris Boesler baembel at gmx.de
Sun Oct 21 10:17:50 PDT 2007


Hi!

>>   I'm writing a new back-end for a new architecture. First, I'll do
>> some "tests" with an existing back-end (I chose the Sparc back-end).
>> My architecture has special address-registers and I want to add such
>> new address-registers to my Sparc back-end.
>> ....
>>   The GlobalAddress for variable c is replaced by an ADD(HI(c), LO
>> (c)) during lowering. I assume the code-generator cant place values
>> in the address registers? All address-registers are elements in the
>> register sets IntRegs and AddrRegs.
>
> /// F3_12 multiclass - Define a normal F3_1/F3_2 pattern in one shot.
> multiclass F3_12<string OpcStr, bits<6> Op3Val, SDNode OpNode> {
> ....
> }
>
> defm ADD   : F3_12<"add", 0b000000, add>;
>
> Instruction ADD output register class is IntRegs. It does not match
> AddrRegs. That's why you are getting the assertion.

  The address register set AddrRegs is a subset of IntRegs. Do you  
compare the register set identifiers instead of the register itself  
and if it is within a set?


> What you need is to define a parallel set of instructions that target
> the address register class.

  Every operand or or target of the 3 address-machine can be a data  
or address register. Then I had to write 8 (2^3) patterns per  
instruction. But register classes/sets are used to fold that. I do  
that since ~1996 (~11 years)! We used BEG as code-generator-generator.


> There
> hasn't been any publicly committed targets that require address
> register class so I haven't spent anytime thinking of a clean
> solution.

  This has nothing to do with address registers! This has to do with  
registers and their sets. Address registers are an obvious / famous  
example, but one can think of other cases. Free your mind! ;-)

  A register can be in multiple sets! If a value is written into a  
register r of class A, then a pattern with class B can match if  
register r is an element of class B. In Bottom Up Pattern Matchers we  
use "chain rules" to transform a non-terminal/register-class to  
another non-terminal/register-class.

  So, what should I do next? What do you suggest? Modify the register  
allocator?

Thanks,
Boris




More information about the llvm-dev mailing list