[PATCH] D53541: [COFF, ARM64] Do not emit x86_seh_recoverfp intrinsic
Reid Kleckner via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Tue Jan 15 11:01:42 PST 2019
rnk added a comment.
I can't compile the example you gave yet because I haven't applied your patches locally, but this is the "three stack pointer" case that I have in mind:
struct Foo {
void (*ptr)();
int x, y, z;
};
void escape(void *);
void large_align(int a0, int a1, int a2, int a3, int a4, int a5, int a6, int a7,
int stackarg) {
struct Foo __declspec(align(32)) alignedlocal;
alignedlocal.x = 42;
int vla[a0];
escape(&alignedlocal);
vla[0] = stackarg;
escape(&vla[0]);
}
This is LLVM's generated code:
"?large_align@@YAXHHHHHHHHH at Z": ; @"?large_align@@YAXHHHHHHHHH at Z"
.seh_proc "?large_align@@YAXHHHHHHHHH at Z"
; %bb.0: ; %entry
stp x21, x22, [sp, #-48]! ; 16-byte Folded Spill
stp x19, x20, [sp, #16] ; 16-byte Folded Spill
stp x29, x30, [sp, #32] ; 16-byte Folded Spill
add x29, sp, #32 ; =32
sub x9, sp, #48 ; =48
and sp, x9, #0xffffffffffffffe0
mov x19, sp
mov w8, #42
str w8, [x19, #8]
mov w8, w0
ldr w22, [x29, #16]
lsl x8, x8, #2
add x8, x8, #15 ; =15
lsr x15, x8, #4
mov x21, sp
bl __chkstk
mov x8, sp
sub x20, x8, x15, lsl #4
mov sp, x20
add x0, x19, #0 ; =0
bl "?escape@@YAXPEAX at Z"
mov x0, x20
str w22, [x20]
bl "?escape@@YAXPEAX at Z"
mov sp, x21
sub sp, x29, #32 ; =32
ldp x29, x30, [sp, #32] ; 16-byte Folded Reload
ldp x19, x20, [sp, #16] ; 16-byte Folded Reload
ldp x21, x22, [sp], #48 ; 16-byte Folded Reload
ret
I see three pointers used to address the stack:
- sp: to address vla
- x19: to address locals, the so-called "base" pointer
- x29: to address parameters on the stack, looks like the traditional FP, points to FP+LR pair as well
At least for x86, the unwind info doesn't describe X19, it just describes X29, since that's what you need to restore CSRs and find the parent stack frame. We saw that the Windows EH runtime passes in some value based on the unwind info. For x86, it was just whatever EBP held, so recoverfp simply aligns that value forward to recover the base pointer (ESI) and then uses that to recover locals. For x64, the runtime passes in the value of RSP after the prologue ends, so we adjust it by the "parent frame offset" to get back the value we put in RBP. It looks like for x64 we never handled the case I'm asking you about, because this program doesn't print the right value:
#include <stdio.h>
struct Foo {
void (*ptr)();
int x, y, z;
};
int filter(int n) {
printf("o.x: %d\n", n);
return 1;
}
void may_throw() {
__builtin_trap();
}
int main() {
struct Foo __declspec(align(32)) o;
o.x = 42;
__try {
may_throw();
} __except(filter(o.x)) {
}
}
I get "o.x: 0" instead of 42. I bet we can find something about that in bugzilla somewhere. =/
So, hopefully that explains the intended purpose of `llvm.x86.seh.recoverfp`, and why we might need to generalize it into something non-x86 specific. Maybe `llvm.eh.recoverfp`. Let me know if I can clarify anything else.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D53541/new/
https://reviews.llvm.org/D53541
More information about the cfe-commits
mailing list