SnoopPrecompile with pkgimages chokes on non-native code about snoopcompile.jl

[vchuravy]

Timings should probably exclude or special handle custom abstract interpreters.

cc: @aviatesk

[maleadt]

Would a viable solution be to specify a module whose code would not be precompiled?

GPU and CPU code is often part of the same module; disabling based on the AbstractInterpreter (involved) seems like the best way.

[aviatesk]

I believe this is basically JuliaLang/julia#48453. If so, GPUCompiler can implement a workaroud on its side. xref: https://github.com/aviatesk/JET.jl/blob/c0adbac27844dd07ee1df7e92689fdc571acba85/src/analyzers/jetanalyzer.jl#L44-L56

[vchuravy]

We will likely run into that next, but this is more that a custom absint is reporting it's timings and those are taking as truth by SnoopCompile. We should note Wich AbsInt cause a timings entry to create

[timholy]

This should be addressed now in Precompiler, since that's the future. (I don't think I can transfer to an organization.) Would a viable solution be to specify a module whose code would not be precompiled?

Note Precompiler/SnoopPrecompile is best for intervening at the "root" of inference, i.e., if the given method is dispatched at runtime. If it's deeper into an inferrable callgraph, we'd have to write code to look for it. In either case, I think the only option would be to nix the entire tree; caching part of an inferrable callgraph but omitting other parts introduces all sorts of trouble.

[vchuravy]

Fixed in JuliaLang/julia#49391 which is also part of 1.9.0-rc3

[timholy]

Thanks!

[timholy]

With exclusion, we may need to do some work to ensure whole "inference trees" are really ready to go, cf JuliaLang/julia#35972. But that's clearly not 1.9 work.