Skip to content

Missing elements in invalidation log #58080

Closed
@timholy

Description

@timholy

#57934 had a side effect of excluding some elements from the invalidation logs processed by SnoopCompile. Here's a MWE. The distinguishing characteristic is the presence of both a poorly-specialized and invoked caller with the same signature:

f(::Integer) = 1
callsfrts(x) = f(Base.inferencebarrier(x)::Signed)
invokesfs(x) = invoke(f, Tuple{Signed}, x)

# compilation
invokesfs(1)                        # invoked callee
callsfrts(1)                        # runtime-dispatched callee

# invalidation
logmeths = ccall(:jl_debug_method_invalidation, Any, (Cint,), 1);
f(::Int) = 2
f(::Signed) = 4
ccall(:jl_debug_method_invalidation, Any, (Cint,), 0);

m = which(f, (Signed,))
m  logmeths

You want the final line to be true (and it was before #57934).

Here's the backedge graph before invalidation:

julia> m = only(methods(f))
f(::Integer)
     @ Main REPL[1]:1

julia> mis = collect(Base.specializations(m))
2-element Vector{Any}:
 MethodInstance for f(::Int64)
 MethodInstance for f(::Signed)

julia> mi = mis[1]
MethodInstance for f(::Int64)

julia> mi.backedges
2-element Vector{Any}:
 Tuple{typeof(f), Signed}
 CodeInstance for MethodInstance for invokesfs(::Int64)

julia> mi2 = mis[2]
MethodInstance for f(::Signed)

julia> mi2.backedges
1-element Vector{Any}:
 CodeInstance for MethodInstance for callsfrts(::Int64)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions