Add max_args specialization escape hatch

[Keno]

We currently have a heuristic

julia/src/gf.c

Line 1227 in 6b934f9

intptr_t nspec = (kwmt == NULL || kwmt == jl_type_type_mt || kwmt == jl_nonfunction_mt || kwmt == jl_kwcall_mt ? definition->nargs + 1 : jl_atomic_load_relaxed(&kwmt->max_args) + 2 + 2 * (mt == jl_kwcall_mt));

that decides how many specializations to generate for a varargs functions. It basically works as follows:

1. If this is one method of some generic functions, look at all the other methods for the same generic function and specialize up to two more than the maximum number of arguments to any other method of this generic function.
2. If not (e.g. it's some (::Foo)(args...) method), specialize up to vararg length of two.

There are several problems with this scheme:

1. It's somewhat ad-hoc and not always applicable. For example, we forcibly override the max_args for invoke here:
   

   julia/base/Base.jl

   Line 115 in 6b934f9

   setfield!(typeof(invoke).name.mt, :max_args, 3, :monotonic) # invoke, f, T, args...

and for afoldl here:

julia/base/operators.jl

Line 578 in 6b934f9

setfield!(typeof(afoldl).name.mt, :max_args, 34, :monotonic)

2. Our general direction has been towards a single unified method table, in which case the per-mt max_args heuristic doesn't work anymore.

3. There's a bit of "spooky action at a distance" going on here where defining additional unrelated methods for a generic function can dramatically affect the performance of a different part of the code.

We should revisit this heuristic and see if we can come up with something that just look at the method itself (to start with, we could try just doing nargs+1 for everything and see what happens) or maybe derives some information from an abstract inference of the function. In addition, we should an escape hatch to the Method object itself that allows overriding the max_method heuristic for use in some of the cases mentioned above.

[topolarity]

I've hit a bit of weirdness with how we specialize Varargs right now. For two arguments, we specialize over the following cases:

foo(::T, ::U) where {T,U}
foo(::T, ::Vararg{T}) where {T}
foo(::T, ::Vararg{Any}) where {T}

This includes quadratically-many methods (due to the first pattern), but if we have any past-the-end elements that get rolled into a Varargs, they are specialized only based on the preceding argument.

This is a little strange to me, but we can keep that behavior if we'd like. The question for this issue is how we want to define max_varargs < 2, where there is no preceding argument. Here's one possible behavior:

# max_varargs = 0
foo() 
foo(::Vararg{Any})
# max_varargs = 1
foo()
foo(::T) where {T}
foo(::Vararg{Any})
# max_varargs = 2
foo()
foo(::T) where {T}
foo(::T, ::U) where {T,U}
foo(::T, ::Vararg{T}) where {T}
foo(::T, ::Vararg{Any})

@Keno any preferences here?

[topolarity]

Never mind. I mis-understood how we were expanding Varargs currently. I believe the correct specialization set for e.g. foo(::Vararg{Any}) is:

foo()
foo(::T) where {T}
foo(::T, ::Vararg{T}) where {T}
foo(::T, ::Vararg{Any}) where {T}

This corresponds to max_varargs = 1 (the current default). Meanwhile, max_varargs = 0 would just be:

foo()
foo(::Vararg{Any})

[staticfloat]

Should this be closed, now that #49320 was merged?