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

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

On Tue, 19 Jun 2007, David A. Greene wrote:
> 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.
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

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

On Tuesday 19 June 2007 11:20, Chris Lattner wrote:
> On Tue, 19 Jun 2007, David A. Greene wrote:
> > 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.
>
> 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?
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