Philip Reames via llvm-dev
2019-Jul-30 18:21 UTC
[llvm-dev] Stackmap offset computation on AArch64
Looking at PrologEpilogInserter and searching for STATEPOINT is a a good starting point. Philip On 7/27/19 2:22 AM, Sam Elliott via llvm-dev wrote:> I think you should be looking in AArch64FrameLowering.cpp. The relevant function is AArch64FrameLowering::getFrameIndexReference, I believe. > > Sam > >> On 26 Jul 2019, at 10:55AM, Loïc Ottet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi all, >> >> I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: >> >> define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { >> entry: >> call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) >> ret i32 addrspace(1)* %ptr >> } >> >> This gets emitted as the following assembly code: >> >> test: // @test >> .cfi_startproc >> // %bb.0: // %entry >> str x30, [sp, #-16]! // 8-byte Folded Spill >> .cfi_def_cfa_offset 16 >> .cfi_offset w30, -16 >> str x0, [sp, #8] >> bl return_i1 >> .Ltmp0: >> ldr x0, [sp, #8] >> ldr x30, [sp], #16 // 8-byte Folded Reload >> ret >> .Lfunc_end0: >> .size test, .Lfunc_end0-test >> .cfi_endproc >> >> The generated stackmap indicates that %ptr is located at offset -8 from the stack pointer, instead of the expected 8. After trying a few other configurations it happens that the offsets are computed relative to the stack pointer of the parent frame instead of the current one. >> >> Can someone point me to the place where the stackmap offsets get computed so I can try to debug this? >> >> Thanks, >> >> Loïc Ottet >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > -- > Sam Elliott > Software Developer - LLVM > lowRISC CIC > selliott at lowrisc.org > -- > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Loïc Ottet via llvm-dev
2019-Jul-31 08:48 UTC
[llvm-dev] Stackmap offset computation on AArch64
Thanks for the pointers! The problem was that the offset was mistakenly computed in the way it should be for Win64 exception handling. This is now fixed by taking the IgnoreSPUpdates argument into account in AArch64FrameLowering::getFrameIndexReferencePreferSP. Loïc> On 30 Jul 2019, at 20:21, Philip Reames <listmail at philipreames.com> wrote: > > Looking at PrologEpilogInserter and searching for STATEPOINT is a a good starting point. > > Philip > > On 7/27/19 2:22 AM, Sam Elliott via llvm-dev wrote: >> I think you should be looking in AArch64FrameLowering.cpp. The relevant function is AArch64FrameLowering::getFrameIndexReference, I believe. >> >> Sam >> >>> On 26 Jul 2019, at 10:55AM, Loïc Ottet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Hi all, >>> >>> I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: >>> >>> define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { >>> entry: >>> call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) >>> ret i32 addrspace(1)* %ptr >>> } >>> >>> This gets emitted as the following assembly code: >>> >>> test: // @test >>> .cfi_startproc >>> // %bb.0: // %entry >>> str x30, [sp, #-16]! // 8-byte Folded Spill >>> .cfi_def_cfa_offset 16 >>> .cfi_offset w30, -16 >>> str x0, [sp, #8] >>> bl return_i1 >>> .Ltmp0: >>> ldr x0, [sp, #8] >>> ldr x30, [sp], #16 // 8-byte Folded Reload >>> ret >>> .Lfunc_end0: >>> .size test, .Lfunc_end0-test >>> .cfi_endproc >>> >>> The generated stackmap indicates that %ptr is located at offset -8 from the stack pointer, instead of the expected 8. After trying a few other configurations it happens that the offsets are computed relative to the stack pointer of the parent frame instead of the current one. >>> >>> Can someone point me to the place where the stackmap offsets get computed so I can try to debug this? >>> >>> Thanks, >>> >>> Loïc Ottet >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> -- >> Sam Elliott >> Software Developer - LLVM >> lowRISC CIC >> selliott at lowrisc.org >> -- >> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Philip Reames via llvm-dev
2019-Jul-31 16:13 UTC
[llvm-dev] Stackmap offset computation on AArch64
Is there an upstream patch? Philip On 7/31/19 1:48 AM, Loïc Ottet wrote:> Thanks for the pointers! The problem was that the offset was mistakenly computed in the way it should be for Win64 exception handling. This is now fixed by taking the IgnoreSPUpdates argument into account in AArch64FrameLowering::getFrameIndexReferencePreferSP. > > Loïc > >> On 30 Jul 2019, at 20:21, Philip Reames <listmail at philipreames.com> wrote: >> >> Looking at PrologEpilogInserter and searching for STATEPOINT is a a good starting point. >> >> Philip >> >> On 7/27/19 2:22 AM, Sam Elliott via llvm-dev wrote: >>> I think you should be looking in AArch64FrameLowering.cpp. The relevant function is AArch64FrameLowering::getFrameIndexReference, I believe. >>> >>> Sam >>> >>>> On 26 Jul 2019, at 10:55AM, Loïc Ottet via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> >>>> Hi all, >>>> >>>> I am trying to implement statepoints for the AArch64 target and I’m running into the issue where the following bitcode: >>>> >>>> define i32 addrspace(1)* @test(i32 addrspace(1)* %ptr) gc "statepoint-example" { >>>> entry: >>>> call token (i64, i32, i1 ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_i1f(i64 0, i32 0, i1 ()* @foo, i32 0, i32 0, i32 0, i32 0, i32 addrspace(1)* %ptr) >>>> ret i32 addrspace(1)* %ptr >>>> } >>>> >>>> This gets emitted as the following assembly code: >>>> >>>> test: // @test >>>> .cfi_startproc >>>> // %bb.0: // %entry >>>> str x30, [sp, #-16]! // 8-byte Folded Spill >>>> .cfi_def_cfa_offset 16 >>>> .cfi_offset w30, -16 >>>> str x0, [sp, #8] >>>> bl return_i1 >>>> .Ltmp0: >>>> ldr x0, [sp, #8] >>>> ldr x30, [sp], #16 // 8-byte Folded Reload >>>> ret >>>> .Lfunc_end0: >>>> .size test, .Lfunc_end0-test >>>> .cfi_endproc >>>> >>>> The generated stackmap indicates that %ptr is located at offset -8 from the stack pointer, instead of the expected 8. After trying a few other configurations it happens that the offsets are computed relative to the stack pointer of the parent frame instead of the current one. >>>> >>>> Can someone point me to the place where the stackmap offsets get computed so I can try to debug this? >>>> >>>> Thanks, >>>> >>>> Loïc Ottet >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> -- >>> Sam Elliott >>> Software Developer - LLVM >>> lowRISC CIC >>> selliott at lowrisc.org >>> -- >>> >>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev