[PATCH] D49364: [ARM] Add support for spilling high registers in Thumb1

[Petr Pavlu via Phabricator via llvm-commits]

petpav01 added a comment.

In https://reviews.llvm.org/D49364#1164005, @efriedma wrote:

> > This is possibly problematic when the register pressure is high because ThumbRegisterInfo::saveScavengerRegister() currently also tries to make use of high register r12.
>
> Also, the constant islands pass can clobber lr.  But given the only way to end up with an "hGPR" register class is inline asm, we could probably work around this issue by excluding ip/lr from allocation order for hGPR.
>
> That said, if we ever want to make the high registers generally allocatable in Thumb1 mode, this patch probably isn't the right solution; instead, we should make the register allocator insert the copy, so we aren't forced to scavenge a register later.


Sorry, the mentioned idea with the copy is not quite clear to me. Could you please explain it a bit more for me?



================
Comment at: lib/Target/ARM/ARMRegisterInfo.td:209
+  // For Thumb1 mode, we don't allocate hi regs as working with them (e.g.
+  // spilling) can be costly.
   let AltOrders = [(add LR, GPR), (trunc GPR, 8)];
----------------
efriedma wrote:
> This comment isn't really right. It's still worth using the high registers, with appropriate cost constraints: there are a few important instructions which can take high registers as inputs (cmp, add, bx/blx), and even if we're just effectively using them as spill slots, it's cheaper than spilling to the stack.
Updated, hopefully it now makes sense.


================
Comment at: lib/Target/ARM/Thumb1InstrInfo.cpp:138-142
+  else if (RC->hasSuperClassEq(&ARM::hGPRRegClass))
+    BuildMI(MBB, I, DL, get(ARM::tSPILL_HREG_RESTORE), DestReg)
+        .addFrameIndex(FI)
+        .addImm(0)
+        .addMemOperand(MMO);
----------------
thopre wrote:
> Can you put a similar comment to the store to stack slot?
Added.


https://reviews.llvm.org/D49364