maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/ARM/dwarf-unwind.ll

85 lines
2.7 KiB
LLVM
Raw Normal View History

ARM/Dwarf: correctly align stack before callee-saved VPRs We were making an attempt to do this by adding an extra callee-saved GPR (so that there was an even number in the list), but when that failed we went ahead and pushed anyway. This had a couple of potential issues: + The .cfi directives we emit misplaced dN because they were based on PrologEpilogInserter's calculation. + Unaligned stores can be less efficient. + Unaligned stores can actually fault (likely only an issue in niche cases, but possible). This adds a final explicit stack adjustment if all other options fail, so that the actual locations of the registers match up with where they should be. llvm-svn: 221320
2014-11-05 08:27:13 +08:00
; RUN: llc -mtriple=thumbv7-netbsd-eabi -o - %s | FileCheck %s
declare void @bar()
; ARM's frame lowering attempts to tack another callee-saved register onto the
; list when it detects a potential misaligned VFP store. However, if there are
; none available it used to just vpush anyway and misreport the location of the
; registers in unwind info. Since there are benefits to aligned stores, it's
; better to correct the code than the .cfi_offset directive.
define void @test_dpr_align(i8 %l, i8 %r) {
; CHECK-LABEL: test_dpr_align:
; CHECK: push.w {r4, r5, r6, r7, r8, r9, r10, r11, lr}
ARM: refactor .cfi_def_cfa_offset emission. We use to track quite a few "adjusted" offsets through the FrameLowering code to account for changes in the prologue instructions as we went and allow the emission of correct CFA annotations. However, we were missing a couple of cases and the code was almost impenetrable. It's easier to just add any stack-adjusting instruction to a list and emit them together. llvm-svn: 222057
2014-11-15 06:45:33 +08:00
; CHECK: .cfi_def_cfa_offset 36
ARM/Dwarf: correctly align stack before callee-saved VPRs We were making an attempt to do this by adding an extra callee-saved GPR (so that there was an even number in the list), but when that failed we went ahead and pushed anyway. This had a couple of potential issues: + The .cfi directives we emit misplaced dN because they were based on PrologEpilogInserter's calculation. + Unaligned stores can be less efficient. + Unaligned stores can actually fault (likely only an issue in niche cases, but possible). This adds a final explicit stack adjustment if all other options fail, so that the actual locations of the registers match up with where they should be. llvm-svn: 221320
2014-11-05 08:27:13 +08:00
; CHECK: sub sp, #4
ARM: refactor .cfi_def_cfa_offset emission. We use to track quite a few "adjusted" offsets through the FrameLowering code to account for changes in the prologue instructions as we went and allow the emission of correct CFA annotations. However, we were missing a couple of cases and the code was almost impenetrable. It's easier to just add any stack-adjusting instruction to a list and emit them together. llvm-svn: 222057
2014-11-15 06:45:33 +08:00
; CHECK: .cfi_def_cfa_offset 40
ARM/Dwarf: correctly align stack before callee-saved VPRs We were making an attempt to do this by adding an extra callee-saved GPR (so that there was an even number in the list), but when that failed we went ahead and pushed anyway. This had a couple of potential issues: + The .cfi directives we emit misplaced dN because they were based on PrologEpilogInserter's calculation. + Unaligned stores can be less efficient. + Unaligned stores can actually fault (likely only an issue in niche cases, but possible). This adds a final explicit stack adjustment if all other options fail, so that the actual locations of the registers match up with where they should be. llvm-svn: 221320
2014-11-05 08:27:13 +08:00
; CHECK: vpush {d8}
; CHECK: .cfi_offset d8, -48
; CHECK-NOT: sub sp
; [...]
; CHECK: bl bar
; CHECK-NOT: add sp
; CHECK: vpop {d8}
; CHECK: add sp, #4
; CHECK: pop.w {r4, r5, r6, r7, r8, r9, r10, r11, pc}
call void asm sideeffect "", "~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{r10},~{r11},~{d8}"()
call void @bar()
ret void
}
; The prologue (but not the epilogue) can be made more space efficient by
; chucking an argument register into the list. Not worth it in general though,
; "sub sp, #4" is likely faster.
define void @test_dpr_align_tiny(i8 %l, i8 %r) minsize {
; CHECK-LABEL: test_dpr_align_tiny:
; CHECK: push.w {r3, r4, r5, r6, r7, r8, r9, r10, r11, lr}
; CHECK-NOT: sub sp
; CHECK: vpush {d8}
; CHECK: .cfi_offset d8, -48
; CHECK-NOT: sub sp
; [...]
; CHECK: bl bar
; CHECK-NOT: add sp
; CHECK: vpop {d8}
; CHECK: add sp, #4
; CHECK: pop.w {r4, r5, r6, r7, r8, r9, r10, r11, pc}
call void asm sideeffect "", "~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{r10},~{r11},~{d8}"()
call void @bar()
ret void
}
; However, we shouldn't do a 2-step align/adjust if there are no DPRs to be
; saved.
define void @test_nodpr_noalign(i8 %l, i8 %r) {
; CHECK-LABEL: test_nodpr_noalign:
; CHECK: push.w {r4, r5, r6, r7, r8, r9, r10, r11, lr}
; CHECK-NOT: sub sp
; CHECK: sub sp, #12
; CHECK-NOT: sub sp
; [...]
; CHECK: bl bar
; CHECK-NOT: add sp
; CHECK: add sp, #12
; CHECK-NOT: add sp
; CHECK: pop.w {r4, r5, r6, r7, r8, r9, r10, r11, pc}
alloca i64
call void asm sideeffect "", "~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{r10},~{r11}"()
call void @bar()
ret void
}
ARM: correctly calculate the offset of FP in its push. When we folded the DPR alignment gap into a push, we weren't noting the extra distance from the beginning of the push to the FP, and so FP ended up pointing at an incorrect offset. The .cfi_def_cfa_offset directives are still wrong in this case, but I think that can be improved by refactoring. llvm-svn: 222056
2014-11-15 06:45:31 +08:00
define void @test_frame_pointer_offset() minsize "no-frame-pointer-elim"="true" {
; CHECK-LABEL: test_frame_pointer_offset:
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
; CHECK: push {r4, r5, r6, r7, lr}
; CHECK: .cfi_def_cfa_offset 20
; CHECK: add r7, sp, #12
; CHECK: .cfi_def_cfa r7, 8
; CHECK-NOT: .cfi_def_cfa_offset
; CHECK: push.w {r7, r8, r9, r10, r11}
ARM: refactor .cfi_def_cfa_offset emission. We use to track quite a few "adjusted" offsets through the FrameLowering code to account for changes in the prologue instructions as we went and allow the emission of correct CFA annotations. However, we were missing a couple of cases and the code was almost impenetrable. It's easier to just add any stack-adjusting instruction to a list and emit them together. llvm-svn: 222057
2014-11-15 06:45:33 +08:00
; CHECK-NOT: .cfi_def_cfa_offset
ARM: correctly calculate the offset of FP in its push. When we folded the DPR alignment gap into a push, we weren't noting the extra distance from the beginning of the push to the FP, and so FP ended up pointing at an incorrect offset. The .cfi_def_cfa_offset directives are still wrong in this case, but I think that can be improved by refactoring. llvm-svn: 222056
2014-11-15 06:45:31 +08:00
call void asm sideeffect "", "~{r4},~{r5},~{r6},~{r7},~{r8},~{r9},~{r10},~{r11},~{d8}"()
call void @bar()
ret void
[ARM] Generate consistent frame records for Thumb2 There is not an official documented ABI for frame pointers in Thumb2, but we should try to emit something which is useful. We use r7 as the frame pointer for Thumb code, which currently means that if a function needs to save a high register (r8-r11), it will get pushed to the stack between the frame pointer (r7) and link register (r14). This means that while a stack unwinder can follow the chain of frame pointers up the stack, it cannot know the offset to lr, so does not know which functions correspond to the stack frames. To fix this, we need to push the callee-saved registers in two batches, with the first push saving the low registers, fp and lr, and the second push saving the high registers. This is already implemented, but previously only used for iOS. This patch turns it on for all Thumb2 targets when frame pointers are required by the ABI, and the frame pointer is r7 (Windows uses r11, so this isn't a problem there). If frame pointer elimination is enabled we still emit a single push/pop even if we need a frame pointer for other reasons, to avoid increasing code size. We must also ensure that lr is pushed to the stack when using a frame pointer, so that we end up with a complete frame record. Situations that could cause this were rare, because we already push lr in most situations so that we can return using the pop instruction. Differential Revision: https://reviews.llvm.org/D23516 llvm-svn: 279506
2016-08-23 17:19:22 +08:00
}