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

[Jakob Stoklund Olesen]

On May 15, 2013, at 4:48 AM, Richard Sandiford <rsandifo at linux.vnet.ibm.com> wrote:

> 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.

Makes sense.

Another option would be to always use the GR32/FPR32 register classes when looking up an encoding, and then use MCRegisterInfo::getMatchingSuperRegister(Reg, SystemZ::subreg_32bit, SuperRC) to find the wider registers.

/jakob