Inline singleton splats

[Keno]

As noted in #36087 and #29114, splatting integers currently has a
performance penalty that is unexpected. For tuples and SimpleVectors,
we have special purpose inliners that will simply inline the
tuple/SimpleVector into the call being splatted. However, for
everything else we'd have to run the iteration protocol to find
out what the values to substitute are. This change does just that,
limited to the case of length-1 (and empty) iterables. Benchmark:

f(x) = (x...,)
@code_typed f(1)
@benchmark f(1)

Before:

julia> @code_typed f(1)
CodeInfo(
1 ─ %1 = Core._apply_iterate(Base.iterate, Core.tuple, x)::Tuple{Int64}
└──      return %1
) => Tuple{Int64}

julia> @benchmark f(1)
BenchmarkTools.Trial:
  memory estimate:  32 bytes
  allocs estimate:  2
  --------------
  minimum time:     209.357 ns (0.00% GC)
  median time:      213.404 ns (0.00% GC)
  mean time:        218.674 ns (0.16% GC)
  maximum time:     1.922 μs (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     540

After:

julia> @code_typed f(1)
CodeInfo(
1 ─ %1 = invoke Base.iterate(_2::Int64)::Tuple{Int64,Nothing}
│   %2 = (getfield)(%1, 1)::Int64
│   %3 = (getfield)(%1, 2)::Nothing
│        invoke Base.iterate(_2::Int64, %3::Nothing)::Nothing
│   %5 = Core.tuple(%2)::Tuple{Int64}
└──      return %5
) => Tuple{Int64}

julia> @benchmark f(1)
BenchmarkTools.Trial:
  memory estimate:  0 bytes
  allocs estimate:  0
  --------------
  minimum time:     3.044 ns (0.00% GC)
  median time:      3.047 ns (0.00% GC)
  mean time:        3.049 ns (0.00% GC)
  maximum time:     7.700 ns (0.00% GC)
  --------------
  samples:          10000
  evals/sample:     1000

Obviously this isn't 100% optimal yet, because the iterate calls themselves
don't get inlined, but it's a lot better. Inlining the iterate calls is
left for a follow up commit.

[martinholters]

I know my way around the optimizer too little to review in detail, but IIUC analyze_type_for_apply_rewrite duplicates a bit of work already done in abstract_iteration during inference. Is that just due to a lack of infrastructure to pipe the information from the latter to the former, or is there some general need to re-establish the types obtained during iteration? (Not that it matters much now, but if we want to get fancier with the inliner in the future, it would be unfortunate to duplicate more of that logic.)

[Keno]

Yes, we don't currently have any infrastructure to forward sideband information from inference to the optimizer (other than the cache for method lookups that we are using here). I'd like to improve that in the future, but for now this is the best we can do.

[martinholters]

Thanks for confirming. (And by all means, that does not mean I disapprove of this PR in its current form in any way.)

[Keno]

Superseded by #36684