TargetRegisterClass for Physical Register

How do I get the TargetRegisterClass for a physical register?
SSARegMap::getRegClass only works for virtual registers.

                                               -Dave

Take a look at getPhysicalRegisterRegClass(
         const MRegisterInfo *MRI,
         MVT::ValueType VT,
         unsigned reg)

in ScheduleDAG.cpp.

Yuck. I was afraid of that.

What is the ValueType needed for? Isn't the register id itself an indication
of the ValueType it represents? Where I'm at I don't have access to a
ValueType.

I understand that a physical register can live in multiple classes (cf.
X86RegisterInfo.td where EAX and others are in GR32 and GR32_,
though the comment says GR32_ is only for 32 bit mode, so it's not
_really_ the case that it's in multiple classes). Does ValueType have
something to do with that?

In the same file, the VR64 register class has the following definition:

def VR64 : RegisterClass<"X86", [v8i8, v4i16, v2i32, v1i64], 64,
                          [MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7]>;

So there are multiple ValueTypes here (the scalar registers each only have
one corresponding to the bit size of the register). But still, if I have
physical register MM2, that completely determines its register class.

Is there some other architecture where the physical register name/number
does not completely determine its register class?

BTW, the Smith Generalized Graph Coloring allocator paper describes their
definition of x86 register classes and there a physical register very much
can live in multiple classes (EAX is in CEX and CEXI for example). I'll
probably have more to say about this as I gain experience. I may want to
introduce some extra classes into the x86 target.

                                                    -Dave

Take a look at getPhysicalRegisterRegClass(
const MRegisterInfo *MRI,
MVT::ValueType VT,
unsigned reg)

in ScheduleDAG.cpp.

Yuck. I was afraid of that.

What is the ValueType needed for? Isn’t the register id itself an indication
of the ValueType it represents? Where I’m at I don’t have access to a
ValueType.

I understand that a physical register can live in multiple classes (cf.
X86RegisterInfo.td where EAX and others are in GR32 and GR32_,
though the comment says GR32_ is only for 32 bit mode, so it’s not
really the case that it’s in multiple classes). Does ValueType have
something to do with that?

In the same file, the VR64 register class has the following definition:

def VR64 : RegisterClass<“X86”, [v8i8, v4i16, v2i32, v1i64], 64,
[MM0, MM1, MM2, MM3, MM4, MM5, MM6, MM7]>;

My guess is this assert is to catch things like trying to get an MVT::v2f32 for MM2, in which case the assert will fire.

So there are multiple ValueTypes here (the scalar registers each only have
one corresponding to the bit size of the register). But still, if I have
physical register MM2, that completely determines its register class.

It doesn’t appear that single class membership is enforced, so one would have to assume not.

Is there some other architecture where the physical register name/number
does not completely determine its register class?

It’s plausible. Imagine a register set like the one you have above, but the first half of the registers do support v2f32 types. One would probably construct a separate register class for those registers and that type.

So there are multiple ValueTypes here (the scalar registers each only have
one corresponding to the bit size of the register). But still, if I have
physical register MM2, that completely determines its register class.

Right.

Is there some other architecture where the physical register name/number
does not completely determine its register class?

Yes, for example, X86. On X86, we have XMM registers that can hold one of three things: an f32 value, a f64 value, or a vector value. These are represented by different register classes containing the same registers.

Likewise, PPC has f32/f64 represented as two different register classes, but has all the F registers in both.

Ugly yes, but this does model the hardware more closely than artificially duplicating each register for each different value type it can hold...

-Chris

> Is there some other architecture where the physical register name/number
> does not completely determine its register class?

Yes, for example, X86. On X86, we have XMM registers that can hold one of
three things: an f32 value, a f64 value, or a vector value. These are
represented by different register classes containing the same registers.

Oops, missed that one. Thanks for pointing it out.

For the Smith register allocator, one needs to know all of the register
classes a physical register can be in, so ValueType isn't relevant there.

Ugly yes, but this does model the hardware more closely than artificially
duplicating each register for each different value type it can hold...

The model is correct, I believe. My "yuck" comment was about the necessity
of iterating through all members of all register classes to find the classes a
physical register is in. It would be nice to have a backmap. Perhaps I'll
fiddle around with TableGen and friends and see about adding one if folks
think it's useful.

                                                       -Dave

Ah, ok. Unless there are a lot of clients, I don't think this is something tblgen should generate. It's a one to many mapping, and any particular client can do a linear scan over the registers to invert the mapping if they need efficient access to the reverse map. Does that make sense?

-Chris

It makes sense not to do it in tblgen. I'm not sure what you mean by
"do a linear scan over the registers to invert the mapping if they need
efficient access to the reverse map." Do you mean construct the reverse
map by iterating over the members of the register class and building it up
explicitly? Yes, absolutely and it's what I'm doing now.

                                                  -Dave

Yep, ok.

-Chris