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

Benjamin Maxwell via llvm-commits llvm-commits at lists.llvm.org
Thu Jun 12 03:52:08 PDT 2025


================
@@ -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();
----------------
MacDue wrote:

I agree this was an unpleasant hack... I've reverted this and instead now find any restored GPR in the epilogue, SVE functions are marked as having a "big stack" so always save at least one GPR we could use. 

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


More information about the llvm-commits mailing list