assertion failure llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:2453: void computeCalleeSaveRegisterPairs(llvm::MachineFunction&, llvm::ArrayRef<llvm::CalleeSavedInfo>, const llvm::TargetRegisterInfo*, llvm::SmallVectorImpl<{anonymous}::RegPairInfo>&, bool): Assertion `(!RPI.isPaired() || (CSI[i].getFrameIdx() + RegInc == CSI[i + RegInc].getFrameIdx())) && "Out of order callee saved regs!"' failed.

[compnerd]

The following (reduced from Swift's Concurrency module) triggers an assertion failure:

; RUN: llc -mtriple aarch64-unknown-windows-msvc -filetype asm -o - %s

declare i8** @llvm.swift.async.context.addr()

define hidden void @f(i8* %0) nounwind {
entry:
  %1 = tail call i8** @llvm.swift.async.context.addr()
  store i8* %0, i8** %1, align 8
  ret void
}

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

[llvmbot]

@llvm/issue-subscribers-bug

[compnerd]

I suspect that this is related to https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp#L3008-L3009

The lowering will see the following CSRs:
$fp $lr $x19 $x20 $x21 $x22

These get assigned the following slots:
$x19 = 0
$x20 = 1
$x21 = 2
$x22 = 3
$fp = 4
$lr = 6

[compnerd]

This seems to be a few different issues that come together - Win AAPCS reveres storage order and lr and fp. The async frame context is stored next to fp to be located easily by the debugger. Unfortunately, this doesn't work very well with the Win AAPCS layout. However, we should be able to insert the async frame context prior to the lr site.

CC: @TNorthover @mstorsjo

[mstorsjo]

Did this work better before 3780a4e where I reordered the callee saved register ordering to better match the windows canonical order? Or is this async frame something that was added later (in e.g. ea0eec6)?

Also cc @efriedma-quic

[compnerd]

I believe that the pointed out commit (/ea0eec69f16e0f1b00fec413986e4e44f6f627fa) is what introduced the async frame record. If my reading of the process is correct, then the values are inverted, and the link register is always the first spilt entity, I think that easiest thing here would be to shuffle the frame record position to be prior to the link register rather than the frame pointer. There would need to be a subsequent change to lldb to account for this difference. Something like this is what I have in mind:

diff --git a/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp b/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
index e4f89542fb99..f31685c0abb6 100644
--- a/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
+++ b/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp
@@ -3011,6 +3011,15 @@ bool AArch64FrameLowering::assignCalleeSavedSpillSlots(
   // stack slots for them.
   MachineFrameInfo &MFI = MF.getFrameInfo();
   auto *AFI = MF.getInfo<AArch64FunctionInfo>();
+
+  bool UsesWinAAPCS = isTargetWindows(MF);
+  if (UsesWinAAPCS && hasFP(MF) && AFI->hasSwiftAsyncContext()) {
+    int FrameIdx = MFI.CreateStackObject(8, Align(8), true);
+    AFI->setSwiftAsyncContextFrameIdx(FrameIdx);
+    if ((unsigned)FrameIdx < MinCSFrameIndex) MinCSFrameIndex = FrameIdx;
+    if ((unsigned)FrameIdx > MaxCSFrameIndex) MaxCSFrameIndex = FrameIdx;
+  }
+
   for (auto &CS : CSI) {
     Register Reg = CS.getReg();
     const TargetRegisterClass *RC = RegInfo->getMinimalPhysRegClass(Reg);
@@ -3024,7 +3033,8 @@ bool AArch64FrameLowering::assignCalleeSavedSpillSlots(
     if ((unsigned)FrameIdx > MaxCSFrameIndex) MaxCSFrameIndex = FrameIdx;
 
     // Grab 8 bytes below FP for the extended asynchronous frame info.
-    if (hasFP(MF) && AFI->hasSwiftAsyncContext() && Reg == AArch64::FP) {
+    if (hasFP(MF) && AFI->hasSwiftAsyncContext() && !UsesWinAAPCS &&
+        Reg == AArch64::FP) {
       FrameIdx = MFI.CreateStackObject(8, Alignment, true);
       AFI->setSwiftAsyncContextFrameIdx(FrameIdx);
       if ((unsigned)FrameIdx < MinCSFrameIndex) MinCSFrameIndex = FrameIdx;