bad inference edges being created sometime

[vtjnash]

There seems to be MethodInstance edges created at some point with bad type information (while building OmniPackage), such as this one:

MethodInstance for convert(::Type, ::Tuple{Vararg{Symbol}}))

There should only be one method for this re-lookup, but obviously that fails quite badly when we try to go verify that fact in the cache. This is unnecessarily expensive. Why does it make that bad edge?

julia> methods(convert, (Type{<:Tuple}, Tuple{Vararg{Symbol}}))
convert(::Type{T}, x::Tuple{Vararg{Any, N}}) where {N, T<:Tuple}
     @ Base essentials.jl:451

[vtjnash]

There is a similar MethodInstance observed for (::Type{Base.IteratorSize})(Type) from Base.IteratorSize(::Type) @ generator.jl:94, which is sometimes making backedges also, even though this signature has >45 methods and therefore should not have edges created to it (it is merely a compilation signature, not the dispatch edge).

[vtjnash]

More similar bugs from inference:

 inserting cconvert(::Type{<:CUDA.CuArrayPtr}, x) @ CUDA ~/.julia/packages/CUDA/ZdCxS/src/pointer.jl:170 invalidated:
   mt_backedges: 1: signature cconvert(T::Type, x) @ Base essentials.jl:537 (formerly cconvert(T::Type, x) @ Base essentials.jl:537) triggered MethodInstance for Base.Unicode.utf8proc_decompose(::String, ::Int64, ::Vector{UInt8}, ::Int64, ::Function) (0 children)
                 2: signature cconvert(T::Type, x) @ Base essentials.jl:537 (formerly cconvert(T::Type, x) @ Base essentials.jl:537) triggered MethodInstance for Base.Unicode.utf8proc_decompose(::String, ::Int64, ::Ptr{Nothing}, ::Int64, ::Function) (0 children)
                 3: signature cconvert(T::Type, x) @ Base essentials.jl:537 (formerly cconvert(T::Type, x) @ Base essentials.jl:537) triggered MethodInstance for Parsers._widen(::T) where T<:Union{Int128, UInt128} (0 children)
   backedges: 1: superseding cconvert(T::Type, x) @ Base essentials.jl:537 with MethodInstance for Base.cconvert(::Type, ::Nothing) (3 children)
              2: superseding cconvert(T::Type, x) @ Base essentials.jl:537 with MethodInstance for Base.cconvert(::Type, ::Function) (110 children)

[gbaraldi]

Could it be SnoopPrecompile doing something weird?

[vtjnash]

No, looks like at least some of this is a concrete-eval bug. For example, here's a what Cthulhu said about one of the calls:

 • %172 = call → cconvert(::Type{Cstring},::Union{Nothing, SubString{String}, String})::String
   %173 = unsafe_convert(::Type{Cstring},::String)::Cstring
v  %174 = cconvert(::Type{Int32},::Int64)::Int32

 • %172 = < concrete eval > cconvert(::Core.Const(Cstring),::Union{Nothing, SubString{String}, String})::String
   %172 = cconvert(::Type{Cstring},::SubString{String})::String
   %172 = cconvert(::Type{Cstring},::String)::String
   ↩
cconvert(T::Type, x) @ Base essentials.jl:537
Variables
  #self#::Core.Const(Base.cconvert)
  T::Core.Const(Cstring)
  x::Core.Const(nothing)

∘ ─ %0 = invoke cconvert(::Type{Cstring},::Nothing)::Union{}
    @ essentials.jl:537 within `cconvert`
1 ─     (x isa T)::Core.Const(false)
└──     goto #3
2 ─     Core.Const(:(return x))::Union{}
3 ┄     Base.convert(T, x)::Union{}
└──     Core.Const(:(return %4))::Union{}

Then we ended up with an edge to cconvert(::Type, ::Nothing), even though that was the wrong edge to record here.

[vtjnash]

Some of the Base.IteratorSize issues come from this sort of thing:

julia> trees[723]
inserting Base.IteratorSize(::Type{<:AxisArrays.Axis}) @ AxisArrays ~/.julia/packages/AxisArrays/v7vf4/src/core.jl:86 invalidated:
   backedges: 1: superseding Base.IteratorSize(::Type) @ Base generator.jl:94 with MethodInstance for Base.IteratorSize(::Type{<:AbstractString}) (26 children)
              2: superseding Base.IteratorSize(::Type) @ Base generator.jl:94 with MethodInstance for Base.IteratorSize(::Type{I} where I<:(Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})) (117 children)
   18 mt_cache

julia> ans.backedges[1]
MethodInstance for Base.IteratorSize(::Type{<:AbstractString}) at depth 0 with 26 children

julia> ans.children
1-element Vector{SnoopCompile.InstanceNode}:
 MethodInstance for Base.IteratorSize(::AbstractString) at depth 1 with 25 children

julia> ans[1].children
6-element Vector{SnoopCompile.InstanceNode}:
 MethodInstance for collect(::Base.Generator{I, Makie.var"#756#757"{Int64}} where I<:AbstractString) at depth 2 with 9 children
 MethodInstance for collect(::Base.Generator{I, typeof(identity)} where I<:AbstractString) at depth 2 with 1 children
 MethodInstance for collect(::Base.Generator{I, Makie.var"#756#757"{Makie.Quaternionf}} where I<:AbstractString) at depth 2 with 3 children
 MethodInstance for collect(::Base.Generator{I, Makie.var"#756#757"{Float32}} where I<:AbstractString) at depth 2 with 2 children
 MethodInstance for collect(::Base.Generator{I, Makie.var"#758#759"{FreeTypeAbstraction.FTFont}} where I<:AbstractString) at depth 2 with 1 children
 MethodInstance for collect(::Base.Generator{I, Makie.var"#756#757"{ColorTypes.RGBA{Float32}}} where I<:AbstractString) at depth 2 with 3 children

[vtjnash]

I think #49404 will fix many of these. The rest likely come from recursion-limiting. I think backedge handling already could handle that case (where MethodInstance might be wider than the Method), but we don't yet have the equivalent code for staticdata_utils.c

[vtjnash]

Looking closer again now, we are losing this other edge too, because of the intersection with Type{Union{}} (though we haven't spent the cycles to compute and detect that)

 inserting Base.IteratorSize(::Type{<:AxisArrays.Axis}) @ AxisArrays ~/.julia/packages/AxisArrays/v7vf4/src/core.jl:86 invalidated:
   backedges: 1: superseding Base.IteratorSize(::Type) @ Base generator.jl:94 with MethodInstance for Base.IteratorSize(::Type{<:AbstractString}) (26 children)
              2: superseding Base.IteratorSize(::Type) @ Base generator.jl:94 with MethodInstance for Base.IteratorSize(::Type{I} where I<:(Base.Pairs{Symbol, V, Tuple{Vararg{Symbol, N}}, NamedTuple{names, T}} where {V, N, names, T<:Tuple{Vararg{Any, N}}})) (114 children)