[all-commits] [llvm/llvm-project] 6f64a6: [AArch64] Initial compiler support for SVE unwind ...

[Eli Friedman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6f64a600649a95141526043b170aa4244d54c94b
      https://github.com/llvm/llvm-project/commit/6f64a600649a95141526043b170aa4244d54c94b
  Author: Eli Friedman <efriedma at quicinc.com>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
    M llvm/lib/Target/AArch64/AArch64CallingConvention.td
    M llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.cpp
    M llvm/lib/Target/AArch64/AArch64InstrInfo.td
    M llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
    A llvm/test/CodeGen/AArch64/framelayout-sve-win.mir
    A llvm/test/CodeGen/AArch64/sve-stack-frame-layout-win.ll
    A llvm/test/CodeGen/AArch64/win-sve.ll

  Log Message:
  -----------
  [AArch64] Initial compiler support for SVE unwind on Windows. (#138609)

Most bits of this are straightforward: when we emit SVE instructions in
the prologue/epilogue, emit corresponding opcodes.

The unfortunately nasty bit is the handling of the frame pointer in
functions that use the SVE calling convention. If we have SVE callee
saves, and need to restore the stack pointer from the frame pointer,
it's impossible to encode callee saves that happen after the frame
pointer. So this patch rearranges the stack to put SVE callee saves
first. This isn't really that complicated on its own, but it leads to a
lot of tricky conditionals (see FPAfterSVECalleeSaves).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications