gf.c: include const-return methods in --trace-compile

[topolarity]

Code that returns a constant value never ends up compiled by LLVM, but we want to log them with --trace-compile since they are inferred / compiled by our own Compiler.

Resolves #58482

[JeffBezanson]

This probably works but it makes me nervous, since all the other calls to this are from jl_compile_method_internal. Is there any way to arrange for this call to also come from that function?

[NHDaly]

@kpamnany to leave a status update on the experiments we tried w/ this PR.
(TL;DR: it caused crashes when backported to our 1.10 build, so we haven't settled on it yet.)

[topolarity]

it caused crashes when backported to our 1.10 build, so we haven't settled on it yet.

This PR is probably not merge-able as-is, but the crashes that @kpamnany encountered are not due to this fix.

They happen when you include the precompile statement in the sysimage build, not when it is generated. Adding a precompile statement should never crash the compiler, so it's a separate bug

[kpamnany]

What @topolarity said. This patch does emit precompile statements for const-return methods just fine. But when we try to build a sysimage including these precompile statements, we saw some strange failures.

On our 1.10 build, we used this patch and generated precompile statements for a sysimage build. We then added:

diff --git a/base/compiler/cicache.jl b/base/compiler/cicache.jl
index 8332777e6d..7bec2ae3ad 100644
--- a/base/compiler/cicache.jl
+++ b/base/compiler/cicache.jl
@@ -56,6 +56,8 @@ function get(wvc::WorldView{InternalCodeCache}, mi::MethodInstance, default)
     r = ccall(:jl_rettype_inferred, Any, (Any, UInt, UInt), mi, first(wvc.worlds), last(wvc.worlds))
     if r === nothing
         return default
+    elseif !isa(r, CodeInstance)
+        println("Expected CodeInstance for ", mi)
     end
     return r::CodeInstance
 end

And tried to build a sysimage. The sysimage built successfully a number of times, but then failed with:

2025-06-25 23:34:18 - PackageCompiler: compiling incremental system image
2025-06-25 23:34:52 Expected CodeInstance for (::Type{Base.IteratorEltype})(Type{Base.Iterators.Flatten{Array{Array{Salsa.DependencyKey, 1}, 1}}}) from (::Type{Base.IteratorEltype})(Type{Base.Iterators.Flatten{I}}) where {I}
2025-06-25 23:34:52 Internal error: encountered unexpected error in runtime:
2025-06-25 23:34:52 TypeError(func=:typeassert, context="", expected=Core.CodeInstance, got=<?#0x7fffaa5dd6d0::<?#0x7fffaa5dd730::(nil)>>)
2025-06-25 23:34:52 thread (1) ijl_type_error_rt at /build/julia-kp-backport-trace-const-return-methods/src/rtutils.c:121
2025-06-25 23:34:52 thread (1) ijl_type_error at /build/julia-kp-backport-trace-const-return-methods/src/rtutils.c:129
2025-06-25 23:34:52 thread (1) get at ./compiler/cicache.jl:62 [inlined]
2025-06-25 23:34:52 thread (1) typeinf_edge at ./compiler/typeinfer.jl:872
2025-06-25 23:34:52 thread (1) abstract_call_method at ./compiler/abstractinterpretation.jl:633
2025-06-25 23:34:52 thread (1) abstract_call_gf_by_type at ./compiler/abstractinterpretation.jl:95
2025-06-25 23:34:52 thread (1) abstract_call_known at ./compiler/abstractinterpretation.jl:2101

That mi corresponded to the following precompile statement:

#=    0.0 =# precompile(Tuple{Type{Base.IteratorEltype}, Type{Base.Iterators.Flatten{Array{Array{Salsa.DependencyKey, 1}, 1}}}}) #= const-return =#

Unfortunately, this did not reproduce in the next 10 runs. :(

Cody then suggested:

diff --git a/src/gf.c b/src/gf.c
index 2933db4229..19be5ece49 100644
--- a/src/gf.c
+++ b/src/gf.c
@@ -517,6 +517,7 @@ JL_DLLEXPORT void jl_mi_cache_insert(jl_method_instance_t *mi JL_ROOTING_ARGUMEN
                                      jl_code_instance_t *ci JL_ROOTED_ARGUMENT JL_MAYBE_UNROOTED)
 {
     JL_GC_PUSH1(&ci);
+    assert(jl_is_code_instance(ci));
     if (jl_is_method(mi->def.method))
         JL_LOCK(&mi->def.method->writelock);
     jl_code_instance_t *oldci = jl_atomic_load_relaxed(&mi->cache);

After a number of no-error runs, we finally saw:

2025-06-27 15:18:29 - PackageCompiler: compiling incremental system image
2025-06-27 15:19:05 julia: /build/julia-kp-backport-trace-const-return-methods/src/gf.c:526: ijl_mi_cache_insert: Assertion `jl_is_code_instance(ci)' failed.
2025-06-27 15:19:05 
2025-06-27 15:19:05 [1100631] signal (6.-6): Aborted
2025-06-27 15:19:05 in expression starting at none:1
2025-06-27 15:19:05 signal (6) thread (1) __pthread_kill_implementation at /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66/lib/libc.so.6 (unknown line)
2025-06-27 15:19:05 signal (6) thread (1) gsignal at /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66/lib/libc.so.6 (unknown line)
2025-06-27 15:19:05 signal (6) thread (1) abort at /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66/lib/libc.so.6 (unknown line)
2025-06-27 15:19:05 signal (6) thread (1) __assert_fail_base.cold at /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66/lib/libc.so.6 (unknown line)
2025-06-27 15:19:05 signal (6) thread (1) __assert_fail at /nix/store/cg9s562sa33k78m63njfn1rw47dp9z0i-glibc-2.40-66/lib/libc.so.6 (unknown line)
2025-06-27 15:19:05 signal (6) thread (1) ijl_mi_cache_insert at /build/julia-kp-backport-trace-const-return-methods/src/gf.c:526
2025-06-27 15:19:05 signal (6) thread (1) setindex! at ./compiler/cicache.jl:13 [inlined]
2025-06-27 15:19:05 signal (6) thread (1) setindex! at ./compiler/cicache.jl:72 [inlined]
2025-06-27 15:19:05 signal (6) thread (1) cache_result! at ./compiler/typeinfer.jl:406
2025-06-27 15:19:05 signal (6) thread (1) _typeinf at ./compiler/typeinfer.jl:283
2025-06-27 15:19:05 signal (6) thread (1) typeinf at ./compiler/typeinfer.jl:216
<snip>

Strangely, the setindex! that calls jl_mi_cache_insert is dispatched on ci being a CodeInstance:

function setindex!(cache::InternalCodeCache, ci::CodeInstance, mi::MethodInstance)
    ccall(:jl_mi_cache_insert, Cvoid, (Any, Any), mi, ci)

And we haven't gotten any further with this investigation.

[topolarity]

It's also worth mentioning that another run at some point showed a GC-based segfault of some kind (iirc), so it's likely that bug is a GC corruption / incorrect-ness of some kind.

[vtjnash]

Resolution is just to use trace-dispatch if that is what you mean, instead of trying to make trace-compile do something unexpected here

[NHDaly]

make trace-compile do something unexpected here

what is unexpected?

My understanding of --trace-compile is: If a dynamic dispatch requires invoking the compilation toolchain before it can proceed, then a precompile statement should be logged for it.

Put differently: If you were running in a binary compiled by juliac, you would hit an error if you hadn't precompiled this signature. That's what --trace-compile tells me.

Talking to @JeffBezanson today, he put it like this: "Users don't really care what is compiled by llvm vs inference. You just
care about what signatures the compiler didn't know about statically."

So i think having a working version of --trace-compile is necessary, and it needs to just report any signatures that invoked any part of the compiler toolchain.