I think that would be sufficient for me.
The case I care about is that there is large body of functions that the dynamic code *could* call, but any particular JITed program will only call a tiny fraction of that. I pre-compile this library to bitcode at build time, and seed the module with it.
If I call llvm::ParseBitcodeFile to pull it in, I incur about a 0.25s overhead. If I use llvm::getLazyBitcodeModule, it's less than 0.01s for small programs, which is fast enough to compile/recompile these functions frequently in an interactive application. I'd very much like to see this kind of gain for MCJIT.
I don't care if it's literally part of MCJIT or provided as a wrapper. Either is fine, as long as I don't have to write it myself (mostly because I don't trust myself to not make it subtly buggy, compared to somebody who deeply knows MCJIT internals).