The target description .td files are allowed to change the default allocation order on a register class by overriding the allocation_order_begin() and allocation_order_end() methods on TargetRegisterClass.
Previously, this was used all the time to filter out stack and frame pointers and other reserved registers. I was able to remove most of these custom allocation orders in the tree because the register allocators are now filtering out the reserved registers.
A few instances remain. For example, x86 needs to remove AH-DH from GR8 in 64-bit mode because of the REX prefix encoding constraints. We don't want to reserve those four registers because they are still useful with some *_NOREX instructions.
It looks like this:
def GR8 : RegisterClass<"X86", [i8], 8,
[AL, CL, DL, AH, CH, DH, BL, BH, SIL, DIL, BPL, SPL,
R8B, R9B, R10B, R11B, R14B, R15B, R12B, R13B]> {
let MethodProtos = [{
iterator allocation_order_begin(const MachineFunction &MF) const;
iterator allocation_order_end(const MachineFunction &MF) const;
}];
let MethodBodies = [{
static const unsigned X86_GR8_AO_64 = {
X86::AL, X86::CL, X86::DL, X86::SIL, X86::DIL,
X86::R8B, X86::R9B, X86::R10B, X86::R11B,
X86::BL, X86::R14B, X86::R15B, X86::R12B, X86::R13B, X86::BPL
};
GR8Class::iterator
GR8Class::allocation_order_begin(const MachineFunction &MF) const {
const TargetMachine &TM = MF.getTarget();
const X86Subtarget &Subtarget = TM.getSubtarget<X86Subtarget>();
if (Subtarget.is64Bit())
return X86_GR8_AO_64;
else
return begin();
}
GR8Class::iterator
GR8Class::allocation_order_end(const MachineFunction &MF) const {
const TargetMachine &TM = MF.getTarget();
const TargetFrameLowering *TFI = TM.getFrameLowering();
const X86Subtarget &Subtarget = TM.getSubtarget<X86Subtarget>();
const X86MachineFunctionInfo *MFI = MF.getInfo<X86MachineFunctionInfo>();
// Does the function dedicate RBP / EBP to being a frame ptr?
if (!Subtarget.is64Bit())
// In 32-mode, none of the 8-bit registers aliases EBP or ESP.
return begin() + 8;
else if (TFI->hasFP(MF) || MFI->getReserveFP())
// If so, don't allocate SPL or BPL.
return array_endof(X86_GR8_AO_64) - 1;
else
// If not, just don't allocate SPL.
return array_endof(X86_GR8_AO_64);
}
}];
}
It is inconvenient to compute the front and back of the same list in two different functions, but the biggest problem with this is that TableGen doesn't understand what is happening. It can't verify that the alternative allocation order makes sense, and it can't infer derived register classes.
Here is an alternative syntax for the same thing:
def GR8 : RegisterClass<"X86", [i8], 8,
[AL, CL, DL, AH, CH, DH, BL, BH, SIL, DIL, BPL, SPL,
R8B, R9B, R10B, R11B, R14B, R15B, R12B, R13B]> {
let AltOrders = [(sub GR8, AH, BH, CH, DH)];
let AltOrderSelect = [{
const TargetMachine &TM = MF.getTarget();
const X86Subtarget &Subtarget = TM.getSubtarget<X86Subtarget>();
return Subtarget.is64Bit();
}];
}
The AltOrders field is a list of dags, each describing an alternative allocation order. The AltOrderSelect field is a snippet of code that returns a number selecting the active allocation order. 0 is the default, 1 is the first AltOrder member etc.
TableGen can help by computing the set difference (sub GR8, AH, BH, CH, DH), there is no need the repeat the entire register list. TableGen can also verify that the alternative allocation orders don't include foreign registers. That would be illegal.
Finally, suppose TableGen wanted to create a register class with the GR8 sub-registers of GR32_NOSP. It would be able to automatically create an allocation order for such a class by basing it on the GR8 order.
I will make this change soon. Out-of-tree targets will need to change their .td files, but most likely they can simply delete the custom allocation orders entirely. That was the case for most of the in-tree targets.
/jakob