[llvm] r181771 - [SystemZ] Match operands to fields by name rather than by order

Richard Sandiford rsandifo at linux.vnet.ibm.com
Wed May 15 04:48:59 PDT 2013


Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
> On May 14, 2013, at 2:36 AM, Richard Sandiford
> <rsandifo at linux.vnet.ibm.com> wrote:
>
>> +
>> +  // Maps of asm register numbers to LLVM register numbers, with 0 indicating
>> +  // an invalid register.  We don't use the register classes directly because
>> +  // they specify the allocation order.
>> +  extern const unsigned GR32Regs[16];
>> +  extern const unsigned GR64Regs[16];
>> +  extern const unsigned GR128Regs[16];
>> +  extern const unsigned FP32Regs[16];
>> +  extern const unsigned FP64Regs[16];
>> +  extern const unsigned FP128Regs[16];
>> }
>
> This shouldn’t be necessary. Callee saved registers are automatically
> moved to the end of the allocation order by the register allocator,
> and reserved registers are filtered out.
>
> In more complicated cases, you can specify an alternative allocation
> order separate from the list of registers in the register class. See
> ARMRegisterInfo.td for AltOrders examples:
>
> // Generic 128-bit vector register class.
> def QPR : RegisterClass<"ARM", [v16i8, v8i16, v4i32, v2i64, v4f32, v2f64], 128,
>                         (sequence "Q%u", 0, 15)> {
>   // Allocate non-VFP2 aliases Q8-Q15 first.
>   let AltOrders = [(rotl QPR, 8)];
>   let AltOrderSelect = [{ return 1; }];
> }
>
> This should make it easy to always have register classes laid out in
> encoding order.

Yeah.  At some point I did wonder about doing this, but in the end the
separate arrays felt cleaner.  It's nice having 16-entry arrays for
128-bit GPRs and FPRs, so that the 32-bit, 64-bit and 128-bit code can
use common routines.  Especially since the pairing rules are different
for 128-bit GPRs and 128-bit FPRs.

The comment could probably do with some improvement though.  Unless there
are objections, I'll change it to:

  // Maps of asm register numbers to LLVM register numbers, with 0 indicating
  // an invalid register.  In principle we could use 32-bit and 64-bit register
  // classes directly, provided that we relegated the GPR allocation order
  // in SystemZRegisterInfo.td to an AltOrder and left the default order
  // as %r0-%r15.  It seems better to provide the same interface for
  // all classes though.

Thanks,
Richard





More information about the llvm-commits mailing list