Precompile packages that call Finch

[willow-ahrens]

precompiling a package which calls finch fails with

ERROR: LoadError: Evaluation into the closed module `Finch` breaks incremental compilation because the side effects will not be permanent. This is likely due to some other module mutating `Finch` with `eval` during precompilation - don't do this.

This is because Finch uses eval.

There's two ways I could see to fix this:

1. We could just say Finch cannot be called during precompilation, but implement caching to disc which would greatly speed it up.
2. Packages which need to precompile finch code could call finch within a @finchcache block, which would allow Finch to eval stuff in that package instead. unfortunately, every package which ever calls finch during precompilation (even as a dependency of a dependency) would need to use a @finchcache block
3. use https://github.com/SciML/RuntimeGeneratedFunctions.jl instead of eval

Either way, this seems highly related to #492

@kylebd99

[vchuravy]

What prevents you from evaling into the callers module? Or is this coming from a non-macro context?

[willow-ahrens]

It's coming from a non-macro context. Unless we always want users to wrap finch code in an @finch_region block, we might not be able to precompile finch code.

[willow-ahrens]

The high-level interface for things like Finch broadcast means that we no longer require the macro.

[willow-ahrens]

I suppose we would only need an @finch_precompile block for use during precompilation.

[vchuravy]

Or you could use an anonymous module?

[willow-ahrens]

Imm assuming I can use the anonymous module to compile the function, then I would need to cache it to disk to preserve it after precompilation?

[vchuravy]

Eh, you would need to root the anonymous module "somewhere" this could be just a list of modules in Finch, but then those get lost after precompilation of a user package. So the user would need to take "ownership" of that module somehow. Which is almost as if they just give you a module to evaluate into...

[vchuravy]

Also I just noticed things like return ctx.nodes.literal(@eval($ex)), that's just getglobal.

[willow-ahrens]

I agree, the right course of action here is to evaluate into the appropriate module. However, if i ask the user for a module during precompile, I also need to ask for modules in packages that depend on packages that use finch. Is there a way to automatically determine the currently precompiling module automatically?

[vchuravy]

If you are willing to depend on runtime internals jl_precompile_toplevel_module is defined during precompilation and will give you the current module.

[willow-ahrens]

another thought: If we cache to disk, we could precompile finch kernels for all other packages that we have cached on disk. If users want FInch to precompile their kernels, they could cache them to disk and then re-do precompile of Finch with Base.compilecache(Base.identify_package("Finch")).

I'm curious about what other projects that require eval do here. Is it common practice to require all downstream kernels to use some sort of @finch_init macro, for each package that uses eval? I know RuntimeGeneratedFunctions does this.