[llvm] [AArch64] Initial compiler support for SVE unwind on Windows. (PR #138609)

Benjamin Maxwell via llvm-commits llvm-commits at lists.llvm.org
Fri May 30 05:06:10 PDT 2025


================
@@ -1874,12 +1899,48 @@ void AArch64FrameLowering::emitPrologue(MachineFunction &MF,
   bool IsWin64 = Subtarget.isCallingConvWin64(F.getCallingConv(), F.isVarArg());
   unsigned FixedObject = getFixedObjectSize(MF, AFI, IsWin64, IsFunclet);
 
+  // Windows unwind can't represent the required stack adjustments if we have
+  // both SVE callee-saves and dynamic stack allocations, and the frame
+  // pointer is before the SVE spills.  The allocation of the frame pointer
+  // must be the last instruction in the prologue so the unwinder can restore
+  // the stack pointer correctly. (And there isn't any unwind opcode for
+  // `addvl sp, x29, -17`.)
+  //
+  // Because of this, we do spills in the opposite order on Windows: first SVE,
+  // then GPRs. The main side-effect of this is that it makes accessing
+  // parameters passed on the stack more expensive.
+  //
+  // We could consider rearranging the spills for simpler cases.
+  bool FPAfterSVECalleeSaves =
+      Subtarget.isTargetWindows() && AFI->getSVECalleeSavedStackSize();
+
----------------
MacDue wrote:

Could you add a check that this is not used with SME hazard padding? With this layout the current locations of the hazard padding don't make sense (and I believe would require an extra hazard padding slot).
```suggestion

  if (AFI->hasStackHazardSlotIndex())
      report_fatal_error("SME hazard padding is not supported on Windows");
```

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


More information about the llvm-commits mailing list