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
Christopher Lamb
2007-Jun-19 02:22 UTC
[LLVMdev] TargetRegisterClass for Physical Register
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