================
@@ -3267,10 +3267,13 @@ bool AArch64FrameLowering::spillCalleeSavedRegisters(
InsertSEH(MIB, TII, MachineInstr::FrameSetup);
} else { // The code when the pair of ZReg is not present
MachineInstrBuilder MIB = BuildMI(MBB, MI, DL, TII.get(StrOpc));
- if (!MRI.isReserved(Reg1))
+ const AArch64RegisterInfo *RegInfo =
+ static_cast<const AArch64RegisterInfo *>(
+ MF.getSubtarget().getRegisterInfo());
+ if (!RegInfo->isStrictlyReservedReg(MF, Reg1))
----------------
efriedma-quic wrote:
> Having getReservedRegs(MF) return different things depending on where it's
> running seems worse than the bug itself.
I think this can happen anyway? For example, with the frame/base pointer.
> With shrink-wrapping the prolog can be in successor blocks, so LR can be live
> on some CFG paths and not others.
Oh, right.
Other possibilities:
- We could mess with the allocation orders so LR isn't allocated, despite being
an allocatable register. This has basically all the properties we want... but
we don't have the necessary infrastructure to make it straightforward.
- We could introduce a distinction between "reserved for regalloc" and "tracked
for liveness". So we'd have registers where we track liveness, but the
register allocator doesn't allocate them.
Maybe worth bringing up on Discourse to see if there are other opinions.
(I'm not trying to make things complicated here, but I really don't want to
take shortcuts when it comes to core MIR datastructures.)
https://github.com/llvm/llvm-project/pull/98073
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
