[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