[llvm-commits] [llvm] r140319 - /llvm/trunk/lib/Target/Mips/MipsRegisterInfo.td

Bruno Cardoso Lopes bruno.cardoso at gmail.com
Thu Sep 22 15:42:01 PDT 2011


On Thu, Sep 22, 2011 at 3:35 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>
> On Sep 22, 2011, at 3:10 PM, Akira Hatanaka wrote:
>
> > Mips64 and Mips32 have the same set of floating point instructions but
> > the organization of the floating point register file is different:
> > Mips64's register file consists of 32 x 64-bit registers, whilie
> > Mips32's register file consists of 16 x 64-bit registers (each 64-bit
> > register consist of a pair of single precision registers).
>
> OK, so the same set of instructions use different register banks depending on the target configuration.
>
> > I was considering making only one out of the two sets of registers
> > available for the register allocator to pick at any time by changing
> > the set of reserved registers. For example, if the target is Mips32,
> > D*_64 registers are reserved, while D* registers are available.
> >
> > Does this make sense?
>
> I think I understand now.
>
> I think your scheme could work, but it is quite confusing to have D1_64 and D1 in the same register class. It would be better to create two separate register classes for f64. One containing D*_64, and one containing D*.
>
> That would require duplicate f64 instruction definitions for 64-bit and 32-bit mode. This is what you want to avoid, right?
>
> An alternative is to use the TRI::getPointerRegClass() hook.  It should really be called getDynamicRegClass(), it is not just for pointers. You can:
>
>  def f64_rc : PointerLikeRegClass<1>;
>
> Then use f64_rc instead of AFGR64 in your f64 FPU instruction definitions, and add a TRI::getPointerRegClass() hook.
>
>
> If you are planning to add MC support, you should know that the MC layer doesn't understand dynamic register classes.  In that case, I think it would be better to duplicate the f64 instructions for 64-bit and 32-bit mode.

+1 for having 2 different reg classes and duplicating the instructions!


--
Bruno Cardoso Lopes
http://www.brunocardoso.cc




More information about the llvm-commits mailing list