Add optimizer support for invoke(f, ::CodeInstance, args...)

[MasonProtter]

(I wrote this with assistance from Gemini since I'm not very used to writing LLVM IR) No longer using that code

This is an attempt to fix #60441. After bumbling around a bit, it seems that the problem is that invoke(f, ::CodeInstance, args...) calls are not turned into Expr(:invoke statements in the IR, but remains as :calls to the invoke builtin which ends up going through the runtime.

There's probably a better way to do this, but the way I found was to just detect these builtin calls in the LLVM IR, and send them to emit_invoke. I'm now detecting InvokeCICallInfos in the inlining step of the optimizer and turning those into Expr(:invokes.

It appears to resolve the issue:

using BenchmarkTools

mysin(x::Float64) = sin(x)
@assert mysin(1.0) == sin(1.0)
const mysin_ci = Base.specialize_method(Base._which(Tuple{typeof(mysin), Float64})).cache

Before this PR:

julia> @btime invoke(mysin, mysin_ci, x) setup=(x=rand())
  24.952 ns (2 allocations: 32 bytes)
0.7024964043721993

After this PR:

julia> @btime invoke(mysin, mysin_ci, x) setup=(x=rand())
  4.748 ns (0 allocations: 0 bytes)
0.32283046823183426

[gbaraldi]

Does this/should this do a world age check?
What is the difference between this and calling an opaque closure?
Could this potentially be used to make a fake codeinst, put an invoke pointer there and call that random invoke pointer?

[MasonProtter]

What is the difference between this and calling an opaque closure?
Could this potentially be used to make a fake codeinst, put an invoke pointer there and call that random invoke pointer?

So just to be clear, I am not proposing introducing a new mechanism here. The new mechanism was already added for v1.12 in #56660. The only thing this PR does is make it so that the mechanism isn't slow to call.

I don't really know what one can or cannot do by messing around with the invoke pointer, presumably arbitrary things, but I'm not sure. Regarding a comparison to opaque closures, I think the idea is that these codeinstances are a bit more 'static', rather than combining runtime data with alternative interpretation. Another difference is that a CodeInstance is just the natural object that running the compiler pipeline on an alternative AbstractInterpreter produces, not an opaque closure. So I think encouraging people to use these instead of opaque closures allows one to operate a bit more closely to how to the compiler works.

I didn't make the feature though, that was @Keno, so maybe he can motivate it a bit more if the linked PR and my crappy explanation isn't sufficient.

Does this/should this do a world age check?

I had initially assumed that emit_invoke would do the worldage check,but I'm not actually seeing it in there, so I guess I probably should add it into here, since the version in the runtime does do a worldage check.

[MasonProtter]

For the world-age check, how do we do that? It seems that the ctx has a min worldage and a max worldage, not a specific worldage. Do I just check that this overlaps with the min and max worldages of the CodeInstance? Or does the worldage check need to be a runtime check rather than compile-time?

[MasonProtter]

Okay, I have

• Added some basic checks making sure that .invoke is non-null. If it is null, we try to compile it like the interpreter does, and if it's still null after that, we just let the interpreter handle stuff like errors
• Checked that the ctx worldage fits within the valid worldages for the codeinst, if not I simply pass it off to the interpreter to handle errors
• Added some basic tests to CompilerDevTools that one can invoke a constant codeinstnace without allocations, check that the invoke pointer will get generated if null, and check that worldage bounds are respected.
• Made Compiler's tests run CompilerDevTools's tests

[MasonProtter]

I have moved all the testing to test/core.jl to live alongside the original tests for invoke(f, ::CodeInstance, ...). This was mostly just because the majority of lines of code in the PR were about changing the test structure, which was probably rather distracting from the content of the PR.

This is now quite minimal and hopefully easy to review.

[Keno]

Seems sensible to me.

[MasonProtter]

Thank you!

Is this backportable to 1.12/1.13?

[Keno]

I think it's ok to backport 1.13. It does open up a bit of a can of worms, but it's in a new and experimental feature.