Varargs invoke is inconsistently inferred about cthulhu.jl HOT 3 OPEN

xref #92

I generally suspect the @code_typed is more reliable, but I'm not sure even that's always true.

from cthulhu.jl.

Thanks. I have another (unrelated?) question:

After running

julia> @noinline function f(x...)
       return x
       end;

julia> g(x) = f(x, 1);

julia> g(1)
(1, 1)

I get

julia> methods(f).ms[1].specializations
svec(MethodInstance for f(::Int64, ::Int64), #undef, #undef, #undef, #undef, #undef, #undef, MethodInstance for f(::Int64, ::Vararg{Int64}))

Why is the specialization f(::Int64, ::Int64) created?

from cthulhu.jl.

Great question, I've been (and sometimes still am) confused about the same thing. The short answer is that specialization of inference is distinct from specialization of codegen.

julia> @noinline function f(x...)
       return x
       end;

julia> g(x) = f(x, 1);

julia> g(1)
(1, 1)

julia> using MethodAnalysis

julia> mis = methodinstances(f)
2-element Vector{Core.MethodInstance}:
 MethodInstance for f(::Int64, ::Int64)
 MethodInstance for f(::Int64, ::Vararg{Int64, N} where N)

julia> mis[1].cache.specptr
Ptr{Nothing} @0x0000000000000000

julia> mis[2].cache.specptr
Ptr{Nothing} @0x00007f007fe42e10

It's the second one which actually runs. But it's been decided (and I generally agree) that it's useful for callers who know more about their argument types to be able to infer the return type. It also can help link, e.g., the callee of a do block to the method in which it's defined (why that might be important: https://julialang.org/blog/2021/01/precompile_tutorial/). You can generally use Base.inferencebarrier(arg) in the caller when you want to prevent even inference-specialization of the callee.

from cthulhu.jl.