Does anyone understand the purpose of this target inpdendent function?
By adding a new register class that is for MIPS16 but not even referencing it, the compiler breaks because of this code.
def CPU16Regs : RegisterClass<"Mips", [i32], 32, (add
// Return Values and Arguments
V0, V1, A0, A1, A2, A3,
// Callee save
S0, S1
)>;
I'm trying to understand how the Arm compiler avoids this problem.
But still, what is the logic here?
Tia.
Reed
Does anyone understand the purpose of this target inpdendent function?
It's actually a leftover from way back when a register would belong to ONE register class. This hasn't been true for a long time, and we have mostly eliminated code making such assumptions.
The function has since been changed to mean "give me the most precise register class containing PhysReg".
By adding a new register class that is for MIPS16 but not even
referencing it, the compiler breaks because of this code.def CPU16Regs : RegisterClass<"Mips", [i32], 32, (add
// Return Values and Arguments
V0, V1, A0, A1, A2, A3,
// Callee save
S0, S1
)>;I'm trying to understand how the Arm compiler avoids this problem.
But still, what is the logic here?
PrologEpilogInsertion wants to spill S0 as a callee-saved register, but storeRegToStackSlot insists that you give it a register class. PEI uses getMinimalPhysRegClass() because it has no other knowledge of the register class.
MipsInstrInfo::storeRegToStackSlot() needs to be aware that register classes can have sub-classes.
Compare:
if (RC == Mips::CPURegsRegisterClass)
Opc = IsN64 ? Mips::SW_P8 : Mips::SW;
else if (RC == Mips::CPU64RegsRegisterClass)
Opc = IsN64 ? Mips::SD_P8 : Mips::SD;
To ARM:
if (ARM::GPRRegClass.hasSubClassEq(RC)) {
/jakob