Statepoint and strange stack map output

IR & Optimizations
1

I have statepoint calls in my generated IR, but for some reason, no matter what values I put in the gc-live bundle, it always gives the same output for every stack map entry:

  Record ID: 43708, instruction offset: 183
    3 locations:
      #1: Constant 0, size: 8
      #2: Constant 1, size: 8
      #3: Constant 0, size: 8
    0 live-outs: [ ]

I have a simple reproducer here: Compiler Explorer (Unfortunately one has to semi-manually parse the stack map output, but it is short enough and matches the output above.)

One other thing I noticed is that the docs give this syntax:

declare token
  @llvm.experimental.gc.statepoint(i64 <id>, i32 <num patch bytes>,
                 ptr elementtype(func_type) <target>,
                 i64 <#call args>, i64 <flags>,
                 ... (call parameters),
                 i64 0, i64 0)

But if you don’t use i32 for <#call args> and <flags>, it gives you an error like this:

/opt/compiler-explorer/clang-trunk/bin/llc: error: /opt/compiler-explorer/clang-trunk/bin/llc: <source>:7:146: error: argument is not of expected type 'i32'
    %res = call token (i64, i32, ptr, i32, i32, ...) @llvm.experimental.gc.statepoint(i64 123, i32 0, ptr elementtype(i32 (i32, %ref)) @process, i64 2, i32 1, i32 %x, %ref %y, i64 0, i64 0) [ "gc-live"(%ref %y) ]

So I guess the docs are incorrect?

2

If I understand you correct, you wonder about the first three locations. They are described in Stack Map Format section. In short, it is a calling convention, flags and amount of deopt locations.

I don’t quite get the second part. What is incorrect? Is seems correct to me.

3

Ah, I see… did this change recently or am I just confused?

As for the second part, in short, the docs say that the fourth and fifth argument are of type i64, but in reality compilation fails unless they are i32.

4

I don’t know, I’ve started working with statepoints since LLVM 10 and it was so since then. Garbage Collection Safepoints in LLVM — LLVM 10 documentation

Yeah! It seems so, from the beginning it has had the following signature and there were no changes in it

def int_experimental_gc_statepoint : Intrinsic<[llvm_token_ty],
                               [llvm_i64_ty, llvm_i32_ty,
                                llvm_anyptr_ty, llvm_i32_ty,
                                llvm_i32_ty, llvm_vararg_ty],
5

And, you’re right: once I add a relocation, I start getting output values again. Thanks for reminding me to read the friendly manual :slight_smile: