The current LLVM-C/Ocaml linker API is very slow when linking many files
together. This patch exposes and additional API that does not destroy
the Linker object between each linking call.
Exposing them is not trivial, because I would have to introduce new types for Flag and a trampoline for the callback. I removed them to be implicit and in line with LLVMLinkModules2. If you really want me to add them, I would prefer to do it as a separate diff.
I realize it’s non-trivial, but our commitment to ABI compatibility makes revising these public interfaces much more difficult after the fact than getting it right up front.
FWIW, the result of the internalize bindings patch you have apply here as well, and you need only provide a thunk to translate the C binding flags to the few linker flags LLVM currently supports. If you’d like, I can generate that binding and tag you in a review, then you can rebase the OCaml bindings on top.
I think the proliferation of non-reentrant/non-threadsafe functions in the API is an issue. (Right now OCaml has a global lock, but a multicore runtime is in works.) The approach in D65138 is better, but still seems error-prone to me; I'll need to take a closer look at the OCaml runtime feature to see if perhaps a better one is possible.
I would personally consider any C API function that does not take a context a (usability) bug, since the LLVM C API is primarily useful for writing bindings from other languages, most of which have some kind of closure mechanism. I think in this case it is clearly justifiable to add an LLVMLinkInModule2 that fixes this.
@whitequark I think I decided to fold the functionality of LLVMLinkInModule2 into the LLVMLinkInModule. Since I'm adding the function in the first place, I thought there is no need to have the C function without those additional parameters.
Or did I misunderstand what you meant by adding the LLVMLinkInModule2?