RFC: CodegenHooks for external language implementations

[maleadt]

Summary: extends the codegen parameters from #19046, adding a hooks struct for users to put callback routines in. If any of the hooks is set, the compiler will call said method instead of emitting code. By using a package like LLVM.jl, those callback routines can then emit code themselves.
See here for example use of this functionality.

Similar to the codegen hooks, this functionality might not be top-notch yet, but I'd prefer to be developing on top of master instead of maintaining my own forks. I'll keep on improving this interface, figuring out exactly which hooks are important, and what the parameters should be (eg. how much of jl_codectx_t should be exposed?). Tests and proper documentation are to follow after that, I don't want to set anything in stone for now.

Except for some patches to LLVM (and a bump to 3.9, see my tb/cuda branch), this is the last required part of functionality for CUDAnative.jl to work on vanilla master.

cc @vchuravy

[vtjnash]

I don't think we want to be adding calls to the runtime system inside codegen. It should actually be OK, since we aren't going to be adding this the result to the JIT, but we should make sure that the interface enforces that you can't add a function to the JIT that has been generated via a hook.

[maleadt]

Added a check to compile_linfo:

if (params != &jl_default_cgparams /* fast path */ &&
    !compare_cgparams(params, &jl_default_cgparams) && params->cached)
    jl_error("functions compiled with custom codegen params mustn't be cached");

[ViralBShah]

Bump - should we merge this? Would be nice to have CUDANative.jl on master.

[maleadt]

I just started working on this again, needs some love after #19416. I'll finish this up before the end of the week.

[maleadt]

Should be good to go, unless somebody has some comments / ideas for improvements.
I'm not all too happy with how it turned out, but normal compilation should be totally unaffected and I hope to be able to replace some of these hooks with better APIs in the future.

[tkelman]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[vtjnash]

lgtm. I would like to merge on top of #17057 though, since there's going to be a trivial conflict with the module_activation hook.

[vchuravy]

The error on i686 looks like a timeout so I restarted the build (backup of the log at https://gist.github.com/vchuravy/adaae760b733b513535fc5e047d31256)

[vchuravy]

@maleadt @vtjnash ready to merge?

[maleadt]

Yeah should be good to go. Let me do a final rebase + CI, and merge if that turns out good.

[vchuravy]

Yeah! 🎆 🍾

[ViralBShah]

Epic.