Ensure methodinstance can be used on abstract types

[wsmoses]

Needed for Enzyme custom rules in Julia 1.11

Let's us revert having to vendor it ourselves in https://github.com/EnzymeAD/Enzyme.jl/pull/1981/files

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 71.39%. Comparing base (3445ea7) to head (facee8b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #644      +/-   ##
==========================================
- Coverage   71.40%   71.39%   -0.01%     
==========================================
  Files          24       24              
  Lines        3224     3223       -1     
==========================================
- Hits         2302     2301       -1     
  Misses        922      922              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[maleadt]

@vtjnash Can you take a look at this? Are these queries valid for non-dispatch tuples?

[wsmoses]

x/ref #635

[vtjnash]

The underlying function this ccalls may assert or segfault without this. There is probably a significant argument to be made that you should be using the public function which(sig) here, which doesn't have that footgun, but it currently doesn't know that it could optimize the isdispatchtuple case by calling jl_method_lookup_by_tt.

[wsmoses]

@maleadt how is this then, we can still use the fast path when legal, but when illegal we use the same path as 1.10.

[maleadt]

The whole idea of the new upstream API was to get rid of the generator, which is fundamentally broken (e.g. #530), so we're not adding that back.

[vchuravy]

Maybe to avoid an X then Y, problem. From the perspective of the Julia compiler and runtime system, the query is ill-formed and, as far as I can tell, Julia itself never does this query.

So the question would be "Why is Enzyme forming this query" and "Can we make this query in Enzyme well-posed"?

[wsmoses]

This primarily comes up in the context of Enzyme custom rules.

Specifically we first call GPUCompiler to generated llvm for a corresponding augmented forward derivative, which returns the original result and a tape.

We then call MethodInstance to get the llvm for the corresponding reverse rule which has the same arguments, plus this additional tape arg.

suppose we were differentiating sin(x)

we would want Enzyme.augmentedforward, Active(1.0) for the forward pass and Enzyme.reverse Active(1.0), tape for the reverse pass where tape is an element of the return of the first call.

Often times (and it’s completely legal) for Julia to not be able to statically determine the concrete tape type, so this could be Any for example.

which leads us to asking for Tuple{typeof(reverse), Active{Float64}, Any}.

Of course the user could specify a concrete tape type so there’s usually a reason why it isn’t (as an example within CUDA.jl we need to compute the tape type), and in these cases performance wise it’s usually better to pass this in as an any (eg as if nospecalize was in the arg). This is the type of case causing the failure.

This worked perfectly fine with the 1.10 and before code in GPUCompiler, but now throws an assertion.