Method.roots no longer contains callees' MethodInstance in 1.12.0-beta versions

[kylincaster]

Hi, and thank you for your amazing work on Julia!

I'm currently developing a static compilation tool called StaticLLVM, which aims to compile Julia code ahead-of-time. A key part of this is statically analyzing the callees of each method.
Previously, this was possible via the roots field of a Core.Method object, which stored a list of objects, including the MethodInstance corresponding to all callees.
Here's a minimal example that used to work:

@noinline add(x) = x + 1
test(x::Int) = x + add(x)
test(2)

mt = methods(test)[1]
mt.roots

In earlier versions (e.g., 1.11.x), the above code would output something like:

4-element Vector{Any}:
 :add
 :test
 Symbol("REPL[2]")
 MethodInstance for add(::Int64)

Thus, it allowed us to obtain the callee MethodInstance for add, enabling us to build the call graph starting from a top-level function (like main).
Thus, the callee of add is obtained, which allowing us to build the call graph from some top function (main)
However, in 1.12.0-beta4, the mt.roots no longer contains these callees MethodInstance.

My questions are:

1. Is this removal intentional or a side effect of internal changes?
2. Is there a recommended replacement or a new API to retrieve the callees of a MethodInstance or Core.Method?
3. If not, would it be possible to reintroduce roots field (even as an internal API) or expose a similar mechanism?

This functionality is crucial for static compilation analysis, and I'd love to align with the direction Julia is taking. Any advice or alternatives would be greatly appreciated.

Thanks again for your time and for all the work on Julia!

[vtjnash]

Accessing the .roots array by the user has always been undefined behavior, which can corrupt memory or cause other parts of the computer to misbehave, since it is not thread-safe and has no content that is valid or correct for the user to access. However, there is a .edges array now in each CodeInstance which provides the functionality you describe. It is not a correct way to implement it (the correct way is to call typeinf_ext with TRIM_SAFE, or to use GPUCompiler such as seen in https://github.com/JuliaLang/AllocCheck.jl/blob/main/src/AllocCheck.jl#L219 to access that functionality with a convenient wrapper)

[kylincaster]

Thank you very much for your suggestion! I’m now able to compile successfully on the latest version of Julia, which is great. @vtjnash

I'm also very interested in using GPUCompiler for our work. However, due to the limited documentation, it’s been quite challenging to get started. Any suggestions or tutorials would be greatly appreciated.

Regarding LLVM IR generation with GPUCompiler, is there a way to generate IR for only the target function, similar to Julia’s native code_llvm, without including all the internal functions it calls?

For example, when compiling the test function, the generated IR includes both test and the internal add function:

define internal fastcc i64 @julia_add_3709(i64 signext %0) unnamed_addr #0 {
top:
   %1 = add i64 %0, 1
   ret i64 %1
}

define i64 @test(i64 signext %0) local_unnamed_addr {
top:
  %1 = call fastcc i64 @julia_add_3709(i64 signext %0)
   %2 = add i64 %1, %0
   ret i64 %2
}

Ideally, we’d like to extract only the IR for the target function (e.g., @test) to make it easier to work in a modular way—processing large projects one function at a time instead of producing a large IR file with all definitions included.

[maleadt]

You can use the only_entry flag, however, note that this is normally meant for reflection, as the design of GPUCompiler.jl is to return all IR needed.