inline inexact method matches, repeated

[vtjnash]

continuation of #6677. that one got closed because I was merging into the printf2 branch, and it merged into master

this inserts a MethodError based on the argument types of the only matching function, then inlines the function, or it's call site, for the exact method match

[JeffBezanson]

This is good but at this point I'm more concerned about the inlining-related performance regressions.

[vtjnash]

The inexact match part of this is disabled amyways, due to a bug in method dispatch, so it just has some additional, unused infrastructure that can be used for testing ideas, and then also corrections to effect_free and tweaks to inline_worthy to directly address the performance issues.

[StefanKarpinski]

disabled amyways, due to a bug in method dispatch

additional, unused infrastructure that can be used for testing ideas

Both of these things sound super ominous.

[JeffBezanson]

Are you sure this is necessary? A static parameter might equal, for example, Array.

[vtjnash]

It shouldn't be necessary -- I was trying to work around #7074, where type inference decides to mutate the static parameter so that it can incorrectly call a blas function requiring Array{Complex{Float64}} with input of Array{Complex}

[JeffBezanson]

Ok; looking at #7074 now.

[JeffBezanson]

Fixed; see if you can remove the workaround.

[vtjnash]

i'm still running into a different issue:

julia> (String, Int64, Any) <: ((Type{TypeVar(:T,Any)}...,),)
false

which is resulting from the following answer from _methods

julia> Base._methods(length, (Type{TypeVar(:T,Base.Top)},), 1)
1-element Array{Any,1}:
 (((Type{T<:Top}...,),),(),length(t::(Any...,)) at tuple.jl:3)

which is determined while computing type inference for length(argtypes) in abstract_call_gf

[JeffBezanson]

I don't get it --- the left side is a 3-tuple and the right side is a 1-tuple. Also String <: Type should of course be false.

Tuples are the only types for which length is applicable, so that looks ok to me.

[vtjnash]

whoops, you're right. i simplified the example wrong:

julia> isa((TypeVar(:T,String), Int64, Any), (Type{TypeVar(:T,Any)}...,))
false

[JeffBezanson]

Hmmm, the TypeVar(:T,String) should not be in there --- as you can see, it's not a type. Any sense of where it came from?

[vtjnash]

not really. i can push my WIP if you want to play around. lookup up the call-stack a bit, you can see sort of see where it starts to gets introduced

(lldb) print jl_(f->linfo)
Base.abstract_call(Type{Void<:T<:Union(Any, Undef)}, Array{Any, 1}, Type{Void<:T<:Union(Any, Undef)}, Base.ObjectIdDict, Base.StaticVarInfo, Expr)
(lldb) print jl_(args[0])
Base.SubString{Void<:T<:String}
(lldb) print jl_(args[1])
Array{Any, 1}[:str, :i, Expr(:call, :prevind, :str, :j)::Any]
(lldb) print jl_(args[2])
(Void<:T<:String, Int64, Any)
(lldb) print jl_(args[3])
Base.ObjectIdDict(ht=Array{Any, 1}[#<null>, #<null>, :r, Any, :#s465, Undef, #<null>, #<null>, :#s458, Bool, #<null>, #<null>, #<null>, #<null>, :#s464, Undef, #<null>, #<null>, :limit, Int64, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, :i, Int64, :k, Any, #<null>, #<null>, #<null>, #<null>, :splitter, Char, :#s461, Bool, #<null>, #<null>, :n, Any, #<null>, #<null>, :#s467, Any, #<null>, #<null>, #<null>, #<null>, :keep_empty, Bool, :j, Any, :strs, Void<:_<:Array{Void<:_<:Base.SubString{Void<:T<:String}, 1}, :#s454, Undef, #<null>, #<null>, :#s466, Any, :str, Void<:T<:String])
(lldb) print jl_(args[4])
Base.StaticVarInfo(sp=(Void<:U<:Array{Void<:T<:Any, Void<:N<:Any}, Void<:_<:Array{Void<:_<:Base.SubString{Void<:T<:String}, 1}, Void<:T<:String, Void<:T<:String), cenv=Base.ObjectIdDict(ht=Array{Any, 1}[#<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>, #<null>]), vars=Array{Any, 1}[:str, :splitter, :limit, :keep_empty, :strs, :i, :n, :r, :#s467, :#s466, :j, :k, :#s454, :#s461, :#s458, :#s465, :#s464], label_counter=15)
(lldb) print jl_(args[5])
Expr(:call, :SubString, :str, :i, Expr(:call, :prevind, :str, :j)::Any)::Any

[vtjnash]

note that the signature of the function abstract_call_gf in which we see the confusion occur is:

(lldb) print jl_(f->linfo)
Base.abstract_call_gf(Type{Void<:T<:Union(Any, Undef)}, Array{Any, 1}, Type{Void<:T<:Union(Any, Undef)}, Expr)
(lldb) print jl_(args[0])
Base.SubString{Void<:T<:String}
(lldb) print jl_(args[1])
Array{Any, 1}[:str, :i, Expr(:call, :prevind, :str, :j)::Any]
(lldb) print jl_(args[2])
(Void<:T<:String, Int64, Any)
(lldb) print jl_(args[3])
Expr(:call, :SubString, :str, :i, Expr(:call, :prevind, :str, :j)::Any)::Any

[JeffBezanson]

Is the problem only appearing with inline_incompletematch_allowed = true ?
If so, we can just keep it false. After all, this PR has two different kinds of changes, which I just love.

[vtjnash]

sure, but that doesn't change the fact that julia dispatched to the wrong method:

julia> f(::Type) = 1
f (generic function with 1 method)

julia> f((TypeVar(:T,String), Int64, Any))
1

[JeffBezanson]

Well, a typevar isn't a type but a tuple with a typevar inside it is --- typevars can be type parameters.

In any case, you have to separate the three issues here: general inlining fixes, the partial match feature, and this dispatch bug if there is one. The bug might block one of those other things, but it will be easier to talk about and triage.

[vtjnash]

it is hard to keep this straight, but I think this is the core of the issue:

julia> Base._methods(g, (Type{TypeVar(:T,Base.Top)},), 2)
1-element Array{Any,1}:
 (((Type{T<:Top}...,),),(),g(::(Type{T<:Top}...,)) at none:1)

whereas, the answer should have been:
(((Union(TypeVar(:T,Top),Type{TypeVar(:T,Top)})...,),),(),g(::(Type{T<:Top}...,)) at none:1)

---

or, alternatively formulated:

julia> Base.typeintersect(Type,Tuple)
(Type{T<:Top}...,)

should have returned:
(Union(Type{T<:Top}, T<:Top)...,)
because a Tuple of TypeVars is also a Type:

julia> isa((TypeVar(:T,Any),), Type)
true

[JeffBezanson]

Maybe we should just make TypeVar a kind of Type.

[vtjnash]

I don't know. However, I'm guessing that Symbols and Ints may share the same issues. I guess there should be a distinction between Type and TypeParam = Union(Type, TypeVar, Int, Symbol)?

[JeffBezanson]

The problem really has to do with tuples, since each tuple may or may not be a type. A tuple of symbols or ints is never a type. However, a tuple of typevars is a type, despite neither tuples nor typevars being types by themselves. Making typevars types would fix this.

[JeffBezanson]

I think we should set inline_incompletematch_allowed = false and merge this.

[JeffBezanson]

update: with this change, #6681 is fixed, #6981 is fixed, but #5011 gets 2x worse.

[vtjnash]

#5011 is a bit of a pathological case. we actually really don't want to be inlining that function, but we are having codegen issues with the alternative. the solution there is to do something more intelligent with the calling convention for variadic calls of leaf-types, such that the values can be passed in an unboxed fashion (or boxed on the stack).

[JeffBezanson]

I agree #5011 is a different beast.

[Keno]

whoa Jeff merged something ;)

[vtjnash]

that's probably somehow my fault.

(this did help to get a few bugs found and fixed along the way)