Support for dynamic method overlays

[vchuravy]

IIRC the way Mixtape is currently doing overlays breaks with dynamic function calls, and thus is not dynamically correct.

1. Case function passed as arguemt

f(func, args...) = func(args...)

2. Case function not inferrable

function f(x)
   g = rand() < 0.5 ? sin : cos
   g(x)
end

The way to fix this (I realized this morning) is to replace all f(args...) with lookup_in_ctx(Ctx, f)(args...) and then writing an inference rule that turns lookup_in_ctx(Ctx, f) into the result of the overlay table. Ctx should be the type and you shan't be allowed to make runtime decisions.

[femtomc]

@vchuravy this appears to work -- tell me what I'm misunderstanding tho

Re (in reference to IIRC) old architecture: I recently changed it to use a much different perspective.

[vchuravy]

Just talked with @aviatesk about this. One would want to pass a context_function in https://github.com/JuliaGPU/GPUCompiler.jl/blob/6301d4155bad9fe7eb4d161cc1ab2ff43c4659b5/src/jlgen.jl#L356

which will turn every apply_generic into context_function(f, args...). And then one can re-enter mixtape from there.

[femtomc]

@vchuravy should this functionality (Mixtape) even live externally from GPUCompiler?

The reason why I ask this is because of AbsInt composition issues outside of native pipeline -- here this is a package with another interpreter (which prevents, I presume, usage of Mixtape and Enzyme, or Mixtape and JET).

And regarding Tom's recent PR: tshort/StaticCompiler.jl#69 I wonder if putting it somewhere close to GPUCompiler is a better idea.