codegen: use compiler trampoline closing over method-instance

[vtjnash]

Uses a trampoline to reduce the number of jump checks to happen during dynamic dispatch. It used to be done this way initially, but that got lost for awhile after the function-types PR. This brings back the ability to directly call a method without going through the dispatch helper function.

(over)estimated performance jump is pretty good for certain cases: 17.31 ns => 13.82 ns

julia> @noinline f(a) = a
julia> g = []
julia> @noinline function unstable_no_alloc(n::Int)
                  for s = 1:n
                      f(g)
                  end
              end
@btime unstable_no_alloc(100_000)

[JeffBezanson]

Yay :)

[vtjnash]

Well, technically I just made generated functions more broken but just cared less about it. Although, as long as we make sure there's none included as part of basecompiler, I think it should not have any impact.

[Keno]

So you're saying I have to abandon my plans for the new optimizer to have a dependency on Cxx.jl? Drat!

[maleadt]

I was just about to port codegen.cpp to LLVM.jl... /s

[tshort]

Don't let that stop you, @maleadt 😃

[vtjnash]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[vtjnash]

@nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[KristofferC]

This should have been a pure merge commit benchmark but the memory regression indicates that #26435 (comment) is active in one of the benchmarks but not the other. I have seen similar things happen multiple times before. I think something is off with nanosoldier... @ararslan

[vtjnash]

pure merge commit benchmark

that's not exactly possible – there's nothing for this commit to merge into, it's already on top of master

[KristofferC]

Was that a side mark or did the point of my post not come across (that the baseline benchmark seems to be wrong).

[ararslan]

Nanosoldier lists the specific commits it's using in the report. Looking through Nanosoldier.jl, I don't see any reason to believe that the commits are being misreported, but maybe there's something I'm missing.

[KristofferC]

My thinking is that after #26435 (comment) (which the baseline should for sure include), the benchmark ["broadcast", "typeargs", "(\"tuple\", 10)"] started to allocate. In this PR, there is a Inf regression of memory allocation in that very same benchmark. An Inf memory regression is only possible if the benchmark doesn't allocate in the baseline but we know that it does. Therefore the baseline cannot be what we think it is. Am I missing something?

[vtjnash]

Maybe actually an issue with that PR? A more recent nanosoldier run on a different PR reports an infinite memory improvement on the same benchmark: #26628

[KristofferC]

I don't see how two PRs against master could result in one giving infinity memory improvement (guaranteeing that it used to allocate before the PR) and one giving infinity memory regression (guaranteeing that it used to not allocate before the PR).

[vtjnash]

Let's just try that again. I've rebased so: @nanosoldier runbenchmarks(ALL, vs = ":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

[vtjnash]

I don't see any commonality between those two reports, so will merge soon.

[StefanKarpinski]

Unfortunately, this lovely feature is implicated as the worst offender in the #26767 compilation slow-down.