[llvm-dev] llvm.experimental.gc.statepoint genarates wrong Stack Map (or does it?)

[Philip Reames via llvm-dev]

Viad,

My initial impression is that you've stumbled across a bug.  I suspect 
that we - the only active users of the deopt info in the statepoint I 
know of - have been inverting the meaning of Direct and Indirect 
throughout our code.  (i.e. we're consistent, but swapped on the 
documented meaning)  I've asked Sanjoy to confirm that, and if he 
believes that is actually the case, we will fix upstream to use Indirect 
in this case.

I'll try to have more information for you early next week.

Can I ask what you're using the deopt information for?  Do you have a 
language runtime which supports deoptimization?  Or are you using it for 
something different?  If so, what?  I'm curious to know how others are 
using the infrastructure.

Philip

On 11/13/2015 03:17 AM, vlad via llvm-dev wrote:
> Hello, list
>
> I am not quite sure if what I'm experiencing is a bug or intentional 
> behavior.
>
> In the code below the result of a function call is a deopt arg to 
> llvm.experimental.gc.statepoint
> (http://llvm.org/docs/Statepoints.html#llvm-experimental-gc-statepoint-intrinsic). 
>
> Therefore a Stack Map containing location of this variable is created 
> upon code generation.
>
> Here's the complete example:
>
>     define i64 addrspace(1)* @func() {
>         %p = inttoptr i64 42 to i64 addrspace(1)*
>         ret i64 addrspace(1)* %p
>     }
>
>     define i8 @main() #0 gc "statepoint-example" {
>         %result = call i64 addrspace(1)* @func()
>
>         %token = call i32 (i64, i32, i64 addrspace(1)* ()*, i32, i32, 
> ...) @llvm.experimental.gc.statepoint.p0f_p1i64f (
>             i64 111, i32 0,
>             i64 addrspace(1)* ()* @func,
>             i32 0, i32 0, i32 0,
>             i32 1,
>             i64 addrspace(1)* %result) ; the only deopt arg
>
>
>         %b = ptrtoint i64 addrspace(1)* %result to i64
>         %c = trunc i64 %b to i8
>         ret i8 %c
>     }
>
>
>     declare i32 @llvm.experimental.gc.statepoint.p0f_p1i64f(i64, i32, 
> i64 addrspace(1)* ()*, i32, i32, ...)
>     declare i64 addrspace(1)* @llvm.experimental.gc.result.p1i64(i32)
>
>     attributes #0 = { "no-frame-pointer-elim"="true" }
>
> I compile with `llc -O3 -x86-asm-syntax=intel`.
>
> Here is the meat of the emitted asm:
>     call    func
>     mov rbx, rax
>     mov qword ptr [rbp - 16], rbx
>     call    func
>
> Here is the corresponding Stack Map Location:
>     .byte   2
>     .byte   8
>     .short  7
>     .long   0
> Which means, according to 
> http://llvm.org/docs/StackMaps.html#stack-map-format, that it's a 
> Direct location rsp + 0 (rsp has DWARF register number 7).
> Which I find is not exactly true, as it should rather be an Indirect 
> location [rsp + 0], or better yet, considering I specified 
> "no-frame-pointer-elim"="true", [rbp - 16].
>
> The only explanation about direct locations in the doc is "If an 
> alloca value is passed directly to a stack map intrinsic, then LLVM 
> may fold the frame index into the stack map as an optimization to 
> avoid allocating a register or stack slot. These frame indices will be 
> encoded as Direct locations in the form BP + Offset." And as far as I 
> can see it's not the case here.
>
> I have a new version of LLVM which I built yesterday.
>
> Please help me understand what's happening here. Thanks in advance
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev