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

[Jameson Nash via llvm-commits]

================
@@ -1874,12 +1899,51 @@ 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();
+
+  if (FPAfterSVECalleeSaves && AFI->hasStackHazardSlotIndex())
+    reportFatalUsageError("SME hazard padding is not supported on Windows");
----------------
vtjnash wrote:

Is this fatal error supposed to be usually unreachable? It seems rather easy to accidentally trigger without having any idea what "SME hazard padding" is supposed to mean to the user, or why that means it is a user error to use any `vscale` operations in a function (reduced from clang which made the alloca):
```
$ cat reduced.ll
target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-p:64:64-i32:32-i64:64-i128:128-n32:64-S128-Fn32"
target triple = "aarch64-w64-windows-gnu"

define void @ssyrk_direct_sme1_2VLx2VL() #0 {
  %1 = alloca <vscale x 16 x i1>, align 2
  store <vscale x 16 x i1> zeroinitializer, ptr %1, align 2
  ret void
}

attributes #0 = { "aarch64_pstate_sm_body" }

$ llc reduced.ll --mtriple=aarch64-w64-mingw32 --mattr=+sve2,+sme
LLVM ERROR: SME hazard padding is not supported on Windows
```

Refs: https://github.com/OpenMathLib/OpenBLAS/issues/5585#issue-3758608878

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