[LLVMdev] TargetRegisterClass for Physical Register

[Christopher Lamb]

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>