[LLVMdev] INSERT_SUBREG node.

Christopher Lamb christopher.lamb at gmail.com
Sun Oct 26 15:34:33 PDT 2008


Hi Sanjiv,

What you have below is the currently expected way of declaring sub  
registers, I agree that it's somewhat inelegant as well as poorly  
documented.

1) Yes, sub register sets start with enumeration number 1. I believe  
this has to do with the layout of some static data structures that  
reserve entry 0...

2) The "duplicate" class entries in SubRegClassList is not really a  
duplicate, but specifies for each SubRegSet the register class that  
is expected for the sub registers in that set. This is needed for  
registers that have sub registers of many different types. So for  
your architecture:

let SubRegClassList = [
	FSR8, // Type of SubRegSet 1
	FSR8  // Type of SubRegSet 2
];

Imagine you have a FSR32 register class, that contains both 16-bit  
and 8-bit sub registers, you may end up with a class list like:

let SubRegClassList = [
	FSR8,  // Type of SubRegSet 1
	FSR8,  // Type of SubRegSet 2
	FSR16, // Type of SubRegSet 3
	FSR16  // Type of SubRegSet 4
];

I think that there are definitely more clear ways of attaching  
SubRegSet's to the class of registers they belong to, as well as  
specifying the sub register type in the set. Perhaps syntax along the  
lines of this:

def FSR16: RegisterClass <"PIC16", [i16], 8, [FSR0, FSR1]> {
   let SubRegClassList = [
	<0, FSR8, [FSR0L, FSR0H]>,
	<1, FSR8, [FSR0H, FSR0L]>
    ];
}

Unfortunately I have little time for TableGen hacking at the moment. =)

On Oct 15, 2008, at 11:21 AM, sanjiv gupta wrote:

> We have 16-bit registers class and want to set both the lo and high
> parts using INSERT_SUBREG.
>
> The workaround is to declare the same SubRegClass twice while  
> declaring
> the SuperRegisterClass. i.e.
>
> def FSR16: RegisterClass <"PIC16", [i16], 8, [FSR0, FSR1]> {
>   let SubRegClassList = [FSR8, FSR8];   // HERE.
> }
>
> SubRegSet : <1, [FSR0, FSR1], [FSR0L, FSR0H]>;
> SubRegSet : <2, [FSR0, FSR1], [FSR0H, FSR0L]>;

--
Christopher Lamb






More information about the llvm-dev mailing list