Library refactor: Move OrcTargetProcess code into the ORC Runtime

[lhames]

The ORC Runtime and OrcTargetProcess library both contain code that is intended to be linked into ORC Executors (programs that execute JIT'd code, as opposed to the Controller programs that link LLVM/ORC and produce JIT'd code). The primary differences between the ORC Runtime and OrcTargetProcess are:

(1) The ORC Runtime is currently always JIT-linked (i.e. linked into the executor via ORC runtime), OrcTargetProcess is always linked ahead of time.

(2) The ORC runtime, as part of compiler-rt, builds much more naturally for multiple target architectures: The desired targets can be specified via CMake options, whereas building OrcTargetProcess for targets other than the host requires cross-compiling LLVM for each desired target.

Proposal:

I think that we can resolve this by merging OrcTargetProcess into the ORC runtime and removing the OrcTargetProcess library.

Potential issues:

• Maintaining functionality for MCJIT-like in-process clients: MCJIT had partial exception handling support for in-process JITs, and did not require a runtime for this. If we moved exception registration to the ORC runtime only then we'd break these clients. We can avoid this by duplicating the exception registration functionality in LLVM. Ditto for code to run static constructors and destructors in-process in a limited, MCJIT-like way. This is a fairly small amount of code to duplicate in order to avoid breaking a large class of users.

• Maintaining functionality for MCJIT-like cross-process clients: This should be an explicit non-goal. If clients want to JIT across process boundaries they should now be required to build and use the ORC runtime. For any client who has mastered cross-process JITing this will probably be a minor inconvenience at worst.

• Cross-process JIT testing: The lli-child-target and llvm-jitlink-executor tools are currently built in LLVM for testing out-of-process JIT support. These would have to be moved to the ORC runtime, and only people building the ORC runtime would be able to use them, or test cross-process JITing. If we accept the limitation above (i.e. the ORC runtime should be required for cross-process support) then this isn't a problem -- clients would have had to build the ORC runtime anyway, and all that changes is who will supply the tools.

Optional pre-linking of parts of ORC-runtime:

We may be able to give clients some control over which parts of the ORC runtime they link into their app ahead of time:

• Some parts of the ORC runtime would now be mandatorily pre-linked (e.g. essential bootstrapping code from OrcTargetProcess).
• Some parts of the ORC runtime have to be JIT-linked (e.g. the dlfcn functions, which link directly against state objects that aren't instantiated until runtime).
• Some parts of the ORC runtime could be optionally pre-linked if they were refactored. E.g. The MachOPlatform class currently has to be JIT-linked (if you want to support multiple instances in one process), but could be refactored to be pre-linkable. Pre-linking would allow clients to reduce JIT-startup time, at the cost of tying their executors more tightly to a specific ORC runtime version.

As we tackle any runtime refactor we'll want to think carefully about the visibility and linking implications of our decisions. If we want to play it safe we could split the ORC runtime into two libraries, one mandatorily pre-linked, the other always JIT-linked, and leave it at that.

[llvmbot]

@llvm/issue-subscribers-orcjit

[lhames]

First step -- 1169586 adds the build system support to move lli-child-target and llvm-jitlink-executor to the ORC runtime.

[lhames]

The TODO mentioned in comments in https://reviews.llvm.org/D150555 should be handled as part of this work, if it hasn't been handled beforehand.