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

[Jakob Stoklund Olesen]

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.

/jakob