llvm dev - Jun 2007 - [LLVMdev] TargetRegisterClass for Physical Register

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

On Jun 18, 2007, at 5:25 PM, David Greene wrote:
> 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]>;
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.
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20070618/68e22114/attachment.html>

On Mon, 18 Jun 2007, David Greene wrote:
> 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

-- 
http://nondot.org/sabre/
http://llvm.org/

On Tuesday 19 June 2007 00:35, Chris Lattner wrote:
> > 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