[llvm] [AArch64][SME] Fix restoring callee-saves from FP with hazard padding (PR #143371)

[Eli Friedman via llvm-commits]

================
@@ -635,31 +635,33 @@ bool AArch64RegisterInfo::hasBasePointer(const MachineFunction &MF) const {
   // Furthermore, if both variable sized objects are present, and the
   // stack needs to be dynamically re-aligned, the base pointer is the only
   // reliable way to reference the locals.
-  if (MFI.hasVarSizedObjects() || MF.hasEHFunclets()) {
-    if (hasStackRealignment(MF))
-      return true;
-
-    auto &ST = MF.getSubtarget<AArch64Subtarget>();
-    const AArch64FunctionInfo *AFI = MF.getInfo<AArch64FunctionInfo>();
-    if (ST.hasSVE() || ST.isStreaming()) {
-      // Frames that have variable sized objects and scalable SVE objects,
-      // should always use a basepointer.
-      if (!AFI->hasCalculatedStackSizeSVE() || AFI->getStackSizeSVE())
-        return true;
-    }
-
+  bool CannotUseSPForSVERestore =
+      MFI.hasVarSizedObjects() || hasStackRealignment(MF);
+  if (CannotUseSPForSVERestore || MF.hasEHFunclets()) {
     // Frames with hazard padding can have a large offset between the frame
     // pointer and GPR locals, which includes the emergency spill slot. If the
     // emergency spill slot is not within range of the load/store instructions
     // (which have a signed 9-bit range), we will fail to compile if it is used.
     // Since hasBasePointer() is called before we know if we have hazard padding
     // or an emergency spill slot we need to enable the basepointer
     // conservatively.
+    auto &ST = MF.getSubtarget<AArch64Subtarget>();
+    const AArch64FunctionInfo *AFI = MF.getInfo<AArch64FunctionInfo>();
     if (ST.getStreamingHazardSize() &&
         !AFI->getSMEFnAttrs().hasNonStreamingInterfaceAndBody()) {
       return true;
     }
 
+    if (hasStackRealignment(MF))
+      return MFI.hasVarSizedObjects() || MF.hasEHFunclets();
----------------
efriedma-quic wrote:

The early return here makes this pretty hard to follow...

We currently have the following cases:

- Moving SP + realignment means we can't use sp or fp to refer to locals
- Moving SP + scalable bits on stack means we can't refer to fixed-size locals cheaply
- Moving SP + large locals means we can't refer to locals cheaply
- Moving SP + hazard padding means we can't refer to locals cheaply, including the emergency spill slot.

This patch adds:
- Stack realignment plus hazard padding means we don't know how to emit the epilogue.

I think I'd prefer to separate that out explicitly, and add a comment explaining it, since it's very different from the reasons for other stuff: the rest are all about referring to locals.

https://github.com/llvm/llvm-project/pull/143371