Stackmap offset computation on AArch64

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

I think you should be looking in AArch64FrameLowering.cpp. The relevant function is AArch64FrameLowering::getFrameIndexReference, I believe.

Sam

Looking at PrologEpilogInserter and searching for STATEPOINT is a a good starting point.

Philip

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

Is there an upstream patch?

Philip