Make the cache token incorporate the entire compile configuration.

[maleadt]

Fixes #560. This is what the split of CompilerJob in CompilerConfig + MethodInstance was intended for.

@vchuravy IIRC you opposed this because of Enzyme storing runtime values in the compiler params, but that could be fixed by having a custom ci_cache_token for Enzyme's compiler job, no?

[vchuravy]

Which part should have been recompiled?

When I went through the stack the sm influenced the native code generation not the inference result.

Since the native code goes into a different cache, we should be reusing the inference result here?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.21%. Comparing base (3c1bc65) to head (a1476a1).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #561      +/-   ##
==========================================
+ Coverage   82.39%   83.21%   +0.82%     
==========================================
  Files          24       24              
  Lines        3334     3331       -3     
==========================================
+ Hits         2747     2772      +25     
+ Misses        587      559      -28     

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

[maleadt]

I guess it's not necessarily the reuse of inference results, but the fact that we key the native cache using the CodeInstance?

GPUCompiler.jl/src/execution.jl

Lines 116 to 120 in 3c1bc65

	# fast path: find an applicable CodeInstance and see if we have compiled it before
	ci = ci_cache_lookup(ci_cache(job), src, world, world)::Union{Nothing,CodeInstance}
	if ci !== nothing && haskey(cache, ci)
	obj = cache[ci]
	end

[vchuravy]

Yeah. My mental model is that we want a third cache layer. Initially I thought adding a field to CI would be helpful JuliaLang/julia#53255

But it really is more a 1:N situation.

(obviously I should have audited that code when I did the original PR)