llvm dev - Jun 2007 - [LLVMdev] 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.

--
Christopher Lamb



On Jun 18, 2007, at 4:52 PM, David A. Greene wrote:
> How do I get the TargetRegisterClass for a physical register?
> SSARegMap::getRegClass only works for virtual registers.
>
>                                                -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Monday 18 June 2007 19:02, Christopher Lamb wrote:
> 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