Momchil Velikov 50a97aacac [AArch64] Async unwind - function prologues
Re-commit of 32e8b550e5439c7e4aafa73894faffd5f25d0d05

This patch rearranges emission of CFI instructions, so the resulting
DWARF and `.eh_frame` information is precise at every instruction.

The current state is that the unwind info is emitted only after the
function prologue. This is fine for synchronous (e.g. C++) exceptions,
but the information is generally incorrect when the program counter is
at an instruction in the prologue or the epilogue, for example:

```
stp	x29, x30, [sp, #-16]!           // 16-byte Folded Spill
mov	x29, sp
.cfi_def_cfa w29, 16
...
```

after the `stp` is executed the (initial) rule for the CFA still says
the CFA is in the `sp`, even though it's already offset by 16 bytes

A correct unwind info could look like:
```
stp	x29, x30, [sp, #-16]!           // 16-byte Folded Spill
.cfi_def_cfa_offset 16
mov	x29, sp
.cfi_def_cfa w29, 16
...
```

Having this information precise up to an instruction is useful for
sampling profilers that would like to get a stack backtrace. The end
goal (towards this patch is just a step) is to have fully working
`-fasynchronous-unwind-tables`.

Reviewed By: danielkiss, MaskRay

Differential Revision: https://reviews.llvm.org/D111411
2022-03-24 16:16:44 +00:00

66 lines
1.8 KiB
LLVM

; RUN: llc -verify-machineinstrs < %s -mtriple=aarch64-none-linux-gnu | FileCheck %s
; RUN: llc -verify-machineinstrs < %s -mtriple=aarch64-none-linux-gnu -frame-pointer=all | FileCheck -check-prefix CHECK-WITHFP-ARM64 %s
; Make sure a reasonably sane prologue and epilogue are
; generated. This test is not robust in the face of an frame-handling
; evolving, but still has value for unrelated changes, I
; believe.
;
; In particular, it will fail when ldp/stp are used for frame setup,
; when FP-elim is implemented, and when addressing from FP is
; implemented.
@var = global i64 0
@local_addr = global i64* null
declare void @foo()
define void @trivial_func() nounwind {
; CHECK-LABEL: trivial_func: // @trivial_func
; CHECK-NEXT: // %bb.0
; CHECK-NEXT: ret
ret void
}
define void @trivial_fp_func() {
; CHECK-LABEL: trivial_fp_func:
; CHECK: str x30, [sp, #-16]!
; CHECK-NOT: mov x29, sp
; CHECK-WITHFP-ARM64-LABEL: trivial_fp_func:
; CHECK-WITHFP-ARM64: stp x29, x30, [sp, #-16]!
; CHECK-WITHFP-ARM64-NEXT: .cfi_def_cfa_offset 16
; CHECK-WITHFP-ARM64-NEXT: mov x29, sp
; CHECK-WITHFP-ARM64-NEXT: .cfi_def_cfa w29, 16
; CHECK-WITHFP-ARM64-NEXT: .cfi_offset w30, -8
; CHECK-WITHFP-ARM64-NEXT: .cfi_offset w29, -16
; Dont't really care, but it would be a Bad Thing if this came after the epilogue.
; CHECK-WITHFP-ARM64: bl foo
; CHECK: bl foo
call void @foo()
ret void
; CHECK: ldr x30, [sp], #16
; CHECK-NEXT: ret
; CHECK-WITHFP-ARM64: ldp x29, x30, [sp], #16
; CHECK-WITHFP-ARM64-NEXT: ret
}
define void @stack_local() {
%local_var = alloca i64
; CHECK-LABEL: stack_local:
; CHECK: sub sp, sp, #16
%val = load i64, i64* @var
store i64 %val, i64* %local_var
; CHECK-DAG: str {{x[0-9]+}}, [sp, #{{[0-9]+}}]
store i64* %local_var, i64** @local_addr
; CHECK-DAG: add {{x[0-9]+}}, sp, #{{[0-9]+}}
ret void
}