inlining: use method match signature for union-spliting

[aviatesk]

In cases where the results of constant inference, like concrete-eval, are used for union-split inlining, isa-blocks are generated using the result.edge.specTypes stored within each result. However, it's been found that the edge returned by abstract interpretation may have been widened by the new @nospecializeinfer, which can result in invalid union-splitting. To address this problem, this commit tweaks the inlining algorithm so that it performs union-split inlining using the original signatures that abstract interpretation used for union-split inference, by using match::MethodMatch.

• fixes Incorrect optimization on typejoin in 1.11+ #53590

[vtjnash]

LGTM. I am a bit concerned about what this means about the indiscriminate use of typeintersection results (spec_types) though. Are we being sufficiently careful to only use this result when we can prove that spec_types <: match.method.sig && spec_types <: argument to ml_matches (e.g. the exactness condition)? I would also guess that checking match.fully_covers is suitable in some cases as an alternative check, since it implies that argument <: match.method.sig && spec_types == argument, which is sufficient although not necessary.

[vtjnash]

Also that once the exactness condition fails on one MethodMatch in the list and so we cannot generate an exact dispatch to it, then we can only accept future method match optimizations from the list that are disjoint from the one that failed (such as concrete methods where allow_abstract=false).

[aviatesk]

If it's not fully_covered, we don't inline dispatches that aren't concrete (

julia/base/compiler/ssair/inlining.jl

Lines 1450 to 1452 in a182880

	elseif !handled_all_cases
	# if we've not seen all candidates, union split is valid only for dispatch tuples
	filter!(case::InliningCase->isdispatchtuple(case.sig), cases)

) and keep the fallback dynamic dispatch (

julia/base/compiler/ssair/inlining.jl

Lines 632 to 639 in a182880

	# We're now in the fall through block, decide what to do
	if !fully_covered
	ssa = insert_node_here!(compact, NewInstruction(stmt, typ, line))
	push!(pn.edges, bb)
	push!(pn.values, ssa)
	insert_node_here!(compact, NewInstruction(GotoNode(join_bb), Union{}, line))
	finish_current_bb!(compact, 0)
	end

), which should take care of the worries. There is a situation where we might inline an abstract dispatch even if it isn't fully_covered, but that's only if there's just one single dispatch candidate.

[vtjnash]

That is not relevant to the distinction I am making. Using spec_types derived from the MethodMatch is incorrect and insufficient to determine whether it is valid to inline a match. Only if match.spec_types <: match.method.sig is that legal, but even then you must be careful that if one case fails that validity check, then all of the ones after that must do more conservative matching. For example, say we decided for whatever reason to ignore f(::Int), then we cannot later choose to handle f(::Any). This can get even trickier if we did union-splitting, since we only sort the lists pre-splitting, so some thing in an earlier union-split list might be required to appear after something in a later list. For example, given the methods:
f(::Int64) = 1; f(::Any) = 2 and the call f(Union{Int32, Int64}), we know the result of union splitting will return the f(::Any) method first (for the Int32 case), then the f(::Int64) method. However it is only legal to use the Int32 if we can also show that the spec_types is safely also a subtype of the argument to ml_matches--otherwise we don't know if we are going to have widened that to f(::Any) (which is still a subtype of the sig, and therefore an expected legal result to have there), and then end up using that method instead of f(::Int64) for an Int64 call. Additionally, we also need to be extra cautious furthermore, since we know the cases may not be entirely disjoint (not just for the supertype Any): for example, the union elements might be Vector{<:Union{Int32,Nothing}} and Vector{<:Union{Int64,Nothing}}.