Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
c87d198c |
| 07-Nov-2024 |
Thomas Fransham <tfransham@gmail.com> |
[ORC] Switch to new visibility macros for JIT debug symbols (#113848)
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
[ORC] Switch to new visibility macros for JIT debug symbols (#113848)
Use LLVM_ALWAYS_EXPORT for __jit_debug_descriptor and
__jit_debug_register_code so there exported even if LLVM is not built as
a shared library.
This is part of the work to enable LLVM_BUILD_LLVM_DYLIB and plugins on
windows #109483.
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
89e6a288 |
| 30-Aug-2024 |
Daniil Fukalov <dfukalov@gmail.com> |
[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial si
[NFC] Add explicit #include llvm-config.h where its macros are used. (#106621)
Without these explicit includes, removing other headers, who implicitly
include llvm-config.h, may have non-trivial side effects.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
626d0fa3 |
| 23-Jan-2024 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[llvm-jitlink-executor] Fix unused function warning with LLVM_ENABLE_THREADS=0 (NFC)
|
#
a93c17c9 |
| 03-Jan-2024 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[llvm-jitlink-executor] Drop else block after noreturn-if (NFC) (#76689)
NFC follow-up from https://github.com/llvm/llvm-project/pull/76236
|
#
40236257 |
| 03-Jan-2024 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[Orc] Deduplicate GDB JIT Interface declarations (NFC) (#76373)
https://github.com/llvm/llvm-project/pull/76236 introduced the forth
copy and it was time to deduplicate. This patch brings it back t
[Orc] Deduplicate GDB JIT Interface declarations (NFC) (#76373)
https://github.com/llvm/llvm-project/pull/76236 introduced the forth
copy and it was time to deduplicate. This patch brings it back to 2,
one in OrcTargetProcess and one in legacy ExecutionEngine.
show more ...
|
#
b7d5b0d0 |
| 03-Jan-2024 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[Orc][examples] Revisit advanced LLJIT examples and tests (#76236)
Some maintenance on implementation and tests:
* Drop manual TargetMachineBuilder setup
* Drop addDebugSupport() in favor of Orc's
[Orc][examples] Revisit advanced LLJIT examples and tests (#76236)
Some maintenance on implementation and tests:
* Drop manual TargetMachineBuilder setup
* Drop addDebugSupport() in favor of Orc's enableDebuggerSupport()
* Check that debug support plugins append jit_code_entry
* Update and reduce sample input
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3 |
|
#
f1aa49ad |
| 20-Aug-2022 |
Anubhab Ghosh <anubhabghosh.me@gmail.com> |
[Orc] Use MapperJITLinkMemoryManager with SharedMemoryMapper in llvm-jitlink tool
MapperJITLinkMemoryManager combined with SharedMemoryMapper can be used in place of EPCGenericJITLinkMemoryManager w
[Orc] Use MapperJITLinkMemoryManager with SharedMemoryMapper in llvm-jitlink tool
MapperJITLinkMemoryManager combined with SharedMemoryMapper can be used in place of EPCGenericJITLinkMemoryManager when running on top of same physical memory. This commit enables it when --use-shared-memory is passed.
Differential Revision: https://reviews.llvm.org/D132369
show more ...
|
Revision tags: llvmorg-15.0.0-rc2 |
|
#
b5f76d83 |
| 04-Aug-2022 |
Lang Hames <lhames@gmail.com> |
[ORC] Ensure that llvm_orc_registerJITLoaderGDBAllocAction is linked into tools.
Add a reference to llvm_orc_registerJITLoaderGDBAllocAction from the linkComponents function in the lli, llvm-jitlink
[ORC] Ensure that llvm_orc_registerJITLoaderGDBAllocAction is linked into tools.
Add a reference to llvm_orc_registerJITLoaderGDBAllocAction from the linkComponents function in the lli, llvm-jitlink, and llvm-jitlink-executor tools. This ensures that llvm_orc_registerJITLoaderGDBAllocAction is not dead-stripped in optimized builds, which may cause failures in these tools.
The llvm_orc_registerJITLoaderGDBAllocAction function was originally added with MachO debugging support in 69be352a1961a, but that patch failed to update the linkComponents functions.
http://llvm.org/PR56817
show more ...
|
Revision tags: llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
8fe3d9df |
| 08-Oct-2021 |
Lang Hames <lhames@gmail.com> |
Revert "[ORC] Move SimpleRemoteEPCServer::Dispatcher into OrcShared."
This reverts commit dfd74db9813b0c7c64038c303726ba43f335e07a.
SimpleRemoteEPC should share dispatch with the ExecutionSession,
Revert "[ORC] Move SimpleRemoteEPCServer::Dispatcher into OrcShared."
This reverts commit dfd74db9813b0c7c64038c303726ba43f335e07a.
SimpleRemoteEPC should share dispatch with the ExecutionSession, rather than having two different dispatch systems on the controller side. SimpleRemoteEPCServer::Dispatch doesn't need to be shared.
show more ...
|
#
dfd74db9 |
| 08-Oct-2021 |
Lang Hames <lhames@gmail.com> |
[ORC] Move SimpleRemoteEPCServer::Dispatcher into OrcShared.
Renames SimpleRemoteEPCServer::Dispatcher to SimpleRemoteEPCDispatcher and moves it into OrcShared. SimpleRemoteEPCServer::ThreadDispatch
[ORC] Move SimpleRemoteEPCServer::Dispatcher into OrcShared.
Renames SimpleRemoteEPCServer::Dispatcher to SimpleRemoteEPCDispatcher and moves it into OrcShared. SimpleRemoteEPCServer::ThreadDispatcher is similarly moved and renamed to DynamicThreadPoolSimpleRemoteEPCDispatcher.
This will allow these classes to be reused by SimpleRemoteEPC on the controller side of the connection.
show more ...
|
#
33dd98e9 |
| 01-Oct-2021 |
Lang Hames <lhames@gmail.com> |
[ORC] Remove ORC RPC.
With the removal of OrcRPCExecutorProcessControl and OrcRPCTPCServer in 6aeed7b19c4 the ORC RPC library no longer has any in-tree users.
Clients needing serialization for ORC
[ORC] Remove ORC RPC.
With the removal of OrcRPCExecutorProcessControl and OrcRPCTPCServer in 6aeed7b19c4 the ORC RPC library no longer has any in-tree users.
Clients needing serialization for ORC should move to Simple Packed Serialization (usually by adopting SimpleRemoteEPC for remote JITing).
show more ...
|
#
175c1a39 |
| 26-Sep-2021 |
Lang Hames <lhames@gmail.com> |
[ORC][llvm-jitlink] Add debugging output to SimpleRemoteEPC (and Server).
Also adds an optional 'debug' argument to the llvm-jitlink-executor tool to enable debug-logging.
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3 |
|
#
78b083db |
| 14-Sep-2021 |
Lang Hames <lhames@gmail.com> |
[ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class
Finalization and deallocation actions are a key part of the upcoming JITLinkMemoryManager redesign: They generalize t
[ORC] Add finalization & deallocation actions, SimpleExecutorMemoryManager class
Finalization and deallocation actions are a key part of the upcoming JITLinkMemoryManager redesign: They generalize the existing finalization and deallocate concepts (basically "copy-and-mprotect", and "munmap") to include support for arbitrary registration and deregistration of parts of JIT linked code. This allows us to register and deregister eh-frames, TLV sections, language metadata, etc. using regular memory management calls with no additional IPC/RPC overhead, which should both improve JIT performance and simplify interactions between ORC and the ORC runtime.
The SimpleExecutorMemoryManager class provides executor-side support for memory management operations, including finalization and deallocation actions.
This support is being added in advance of the rest of the memory manager redesign as it will simplify the introduction of an EPC based RuntimeDyld::MemoryManager (since eh-frame registration/deregistration will be expressible as actions). The new RuntimeDyld::MemoryManager will in turn allow us to remove older remote allocators that are blocking the rest of the memory manager changes.
show more ...
|
#
bb72f073 |
| 11-Sep-2021 |
Lang Hames <lhames@gmail.com> |
Re-apply bb27e456435 and 5629afea910 with fixes.
This reapplies bb27e4564355243e479cab40885d6e0f7f640572 (SimpleRemoteEPC support) and 2269a941a450a0d395161cfb792be58870b2875b (#include <mutex> fix)
Re-apply bb27e456435 and 5629afea910 with fixes.
This reapplies bb27e4564355243e479cab40885d6e0f7f640572 (SimpleRemoteEPC support) and 2269a941a450a0d395161cfb792be58870b2875b (#include <mutex> fix) with further fixes to support building with LLVM_ENABLE_THREADS=Off.
show more ...
|
#
2269a941 |
| 11-Sep-2021 |
Lang Hames <lhames@gmail.com> |
Revert 5629afea910 and bb27e456435 while I look into bot failures.
This reverts commit 5629afea9109d3b72064cbe70e1ca91ffb9dc0a2 ("[ORC] Add missing include."), and bb27e4564355243e479cab40885d6e0f7f
Revert 5629afea910 and bb27e456435 while I look into bot failures.
This reverts commit 5629afea9109d3b72064cbe70e1ca91ffb9dc0a2 ("[ORC] Add missing include."), and bb27e4564355243e479cab40885d6e0f7f640572 ("[ORC] Add SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.").
The SimpleRemoteEPC patch currently assumes availability of threads, and needs to be rewritten with LLVM_ENABLE_THREADS guards.
show more ...
|
#
bb27e456 |
| 07-Sep-2021 |
Lang Hames <lhames@gmail.com> |
[ORC] Add SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.
SimpleRemoteEPC is an ExecutorProcessControl implementation (with corresponding new server class) that uses ORC Simpl
[ORC] Add SimpleRemoteEPC: ExecutorProcessControl over SPS + abstract transport.
SimpleRemoteEPC is an ExecutorProcessControl implementation (with corresponding new server class) that uses ORC SimplePackedSerialization (SPS) to serialize and deserialize EPC-messages to/from byte-buffers. The byte-buffers are sent and received via a new SimpleRemoteEPCTransport interface that can be implemented to run SimpleRemoteEPC over whatever underlying transport system (IPC, RPC, network sockets, etc.) best suits your use case.
The SimpleRemoteEPCServer class provides executor-side support. It uses a customizable SimpleRemoteEPCServer::Dispatcher object to dispatch wrapper function calls to prevent the RPC thread from being blocked (a problem in some earlier remote-JIT server implementations). Almost all functionality (beyond the bare basics needed to bootstrap) is implemented as wrapper functions to keep the implementation simple and uniform.
Compared to previous remote JIT utilities (OrcRemoteTarget*, OrcRPCExecutorProcessControl), more consideration has been given to disconnection and error handling behavior: Graceful disconnection is now always initiated by the ORC side of the connection, and failure at either end (or in the transport) will result in Errors being delivered to both ends to enable controlled tear-down of the JIT and Executor (in the Executor's case this means "as controlled as the JIT'd code allows").
The introduction of SimpleRemoteEPC will allow us to remove other remote-JIT support from ORC (including the legacy OrcRemoteTarget* code used by lli, and the OrcRPCExecutorProcessControl and OrcRPCEPCServer classes), and then remove ORC RPC itself.
The llvm-jitlink and llvm-jitlink-executor tools have been updated to use SimpleRemoteEPC over file descriptors. Future commits will move lli and other tools and example code to this system, and remove ORC RPC.
show more ...
|
Revision tags: llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
#
bb5f97e3 |
| 14-Jul-2021 |
Lang Hames <lhames@gmail.com> |
[ORC][ORC-RT] Introduce ORC-runtime based MachO-Platform.
Adds support for MachO static initializers/deinitializers and eh-frame registration via the ORC runtime.
This commit introduces cooperative
[ORC][ORC-RT] Introduce ORC-runtime based MachO-Platform.
Adds support for MachO static initializers/deinitializers and eh-frame registration via the ORC runtime.
This commit introduces cooperative support code into the ORC runtime and ORC LLVM libraries (especially the MachOPlatform class) to support macho runtime features for JIT'd code. This commit introduces support for static initializers, static destructors (via cxa_atexit interposition), and eh-frame registration. Near-future commits will add support for MachO native thread-local variables, and language runtime registration (e.g. for Objective-C and Swift).
The llvm-jitlink tool is updated to use the ORC runtime where available, and regression tests for the new MachOPlatform support are added to compiler-rt.
Notable changes on the ORC runtime side:
1. The new macho_platform.h / macho_platform.cpp files contain the bulk of the runtime-side support. This includes eh-frame registration; jit versions of dlopen, dlsym, and dlclose; a cxa_atexit interpose to record static destructors, and an '__orc_rt_macho_run_program' function that defines running a JIT'd MachO program in terms of the jit- dlopen/dlsym/dlclose functions.
2. Replaces JITTargetAddress (and casting operations) with ExecutorAddress (copied from LLVM) to improve type-safety of address management.
3. Adds serialization support for ExecutorAddress and unordered_map types to the runtime-side Simple Packed Serialization code.
4. Adds orc-runtime regression tests to ensure that static initializers and cxa-atexit interposes work as expected.
Notable changes on the LLVM side:
1. The MachOPlatform class is updated to:
1.1. Load the ORC runtime into the ExecutionSession. 1.2. Set up standard aliases for macho-specific runtime functions. E.g. ___cxa_atexit -> ___orc_rt_macho_cxa_atexit. 1.3. Install the MachOPlatformPlugin to scrape LinkGraphs for information needed to support MachO features (e.g. eh-frames, mod-inits), and communicate this information to the runtime. 1.4. Provide entry-points that the runtime can call to request initializers, perform symbol lookup, and request deinitialiers (the latter is implemented as an empty placeholder as macho object deinits are rarely used). 1.5. Create a MachO header object for each JITDylib (defining the __mh_header and __dso_handle symbols).
2. The llvm-jitlink tool (and llvm-jitlink-executor) are updated to use the runtime when available.
3. A `lookupInitSymbolsAsync` method is added to the Platform base class. This can be used to issue an async lookup for initializer symbols. The existing `lookupInitSymbols` method is retained (the GenericIRPlatform code is still using it), but is deprecated and will be removed soon.
4. JIT-dispatch support code is added to ExecutorProcessControl.
The JIT-dispatch system allows handlers in the JIT process to be associated with 'tag' symbols in the executor, and allows the executor to make remote procedure calls back to the JIT process (via __orc_rt_jit_dispatch) using those tags.
The primary use case is ORC runtime code that needs to call bakc to handlers in orc::Platform subclasses. E.g. __orc_rt_macho_jit_dlopen calling back to MachOPlatform::rt_getInitializers using __orc_rt_macho_get_initializers_tag. (The system is generic however, and could be used by non-runtime code).
The new ExecutorProcessControl::JITDispatchInfo struct provides the address (in the executor) of the jit-dispatch function and a jit-dispatch context object, and implementations of the dispatch function are added to SelfExecutorProcessControl and OrcRPCExecutorProcessControl.
5. OrcRPCTPCServer is updated to support JIT-dispatch calls over ORC-RPC.
6. Serialization support for StringMap is added to the LLVM-side Simple Packed Serialization code.
7. A JITLink::allocateBuffer operation is introduced to allocate writable memory attached to the graph. This is used by the MachO header synthesis code, and will be generically useful for other clients who want to create new graph content from scratch.
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
#
f21cc55f |
| 22-Mar-2021 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[llvm-jitlink] Add diagnostic output and port executor to getaddrinfo(3) as well
Add diagnostic output for TCP connections on both sides, llvm-jitlink and llvm-jitlink-executor. Port the executor to
[llvm-jitlink] Add diagnostic output and port executor to getaddrinfo(3) as well
Add diagnostic output for TCP connections on both sides, llvm-jitlink and llvm-jitlink-executor. Port the executor to use getaddrinfo(3) as well. This makes the code more symmetric and seems to be the recommended way for implementing the server side.
Reviewed By: rzurob
Differential Revision: https://reviews.llvm.org/D98581
show more ...
|
Revision tags: llvmorg-12.0.0-rc3 |
|
#
ef238923 |
| 02-Mar-2021 |
Stefan Gränitz <stefan.graenitz@gmail.com> |
[Orc] Add JITLink debug support plugin for ELF x86-64
Add a new ObjectLinkingLayer plugin `DebugObjectManagerPlugin` and infrastructure to handle creation of `DebugObject`s as well as their registra
[Orc] Add JITLink debug support plugin for ELF x86-64
Add a new ObjectLinkingLayer plugin `DebugObjectManagerPlugin` and infrastructure to handle creation of `DebugObject`s as well as their registration in OrcTargetProcess. The current implementation only covers ELF on x86-64, but the infrastructure is not limited to that.
The journey starts with a new `LinkGraph` / `JITLinkContext` pair being created for a `MaterializationResponsibility` in ORC's `ObjectLinkingLayer`. It sends a `notifyMaterializing()` notification, which is forwarded to all registered plugins. The `DebugObjectManagerPlugin` aims to create a `DebugObject` form the provided target triple and object buffer. (Future implementations might create `DebugObject`s from a `LinkGraph` in other ways.) On success it will track it as the pending `DebugObject` for the `MaterializationResponsibility`.
This patch only implements the `ELFDebugObject` for `x86-64` targets. It follows the RuntimeDyld approach for debug object setup: it captures a copy of the input object, parses all section headers and prepares to patch their load-address fields with their final addresses in target memory. It instructs the plugin to report the section load-addresses once they are available. The plugin overrides `modifyPassConfig()` and installs a JITLink post-allocation pass to capture them.
Once JITLink emitted the finalized executable, the plugin emits and registers the `DebugObject`. For emission it requests a new `JITLinkMemoryManager::Allocation` with a single read-only segment, copies the object with patched section load-addresses over to working memory and triggers finalization to target memory. For registration, it notifies the `DebugObjectRegistrar` provided in the constructor and stores the previously pending`DebugObject` as registered for the corresponding MaterializationResponsibility.
The `DebugObjectRegistrar` registers the `DebugObject` with the target process. `llvm-jitlink` uses the `TPCDebugObjectRegistrar`, which calls `llvm_orc_registerJITLoaderGDBWrapper()` in the target process via `TargetProcessControl` to emit a `jit_code_entry` compatible with the GDB JIT interface [1]. So far the implementation only supports registration and no removal. It appears to me that it wouldn't raise any new design questions, so I left this as an addition for the near future.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/JIT-Interface.html
Reviewed By: lhames
Differential Revision: https://reviews.llvm.org/D97335
show more ...
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
#
5efc71e1 |
| 29-Dec-2020 |
Lang Hames <lhames@gmail.com> |
[ORC] Move Orc RPC code into Shared, rename some RPC types.
Moves all headers from Orc/RPC to Orc/Shared, and from the llvm::orc::rpc namespace into llvm::orc::shared. Also renames RPCTypeName to Se
[ORC] Move Orc RPC code into Shared, rename some RPC types.
Moves all headers from Orc/RPC to Orc/Shared, and from the llvm::orc::rpc namespace into llvm::orc::shared. Also renames RPCTypeName to SerializationTypeName and Function to RPCFunction.
In addition to being a more reasonable home for this code, this will make it easier for the upcoming Orc runtime to re-use the Serialization system for creating and parsing wrapper-function binary blobs.
show more ...
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
#
f2980e88 |
| 13-Nov-2020 |
Lang Hames <lhames@gmail.com> |
[ORC] Fix missing return value.
|
#
1d0676b5 |
| 11-Nov-2020 |
Lang Hames <lhames@gmail.com> |
[ORC] Break up OrcJIT library, add Orc-RPC based remote TargetProcessControl implementation.
This patch aims to improve support for out-of-process JITing using OrcV2. It introduces two new class tem
[ORC] Break up OrcJIT library, add Orc-RPC based remote TargetProcessControl implementation.
This patch aims to improve support for out-of-process JITing using OrcV2. It introduces two new class templates, OrcRPCTargetProcessControlBase and OrcRPCTPCServer, which together implement the TargetProcessControl API by forwarding operations to an execution process via an Orc-RPC Endpoint. These utilities are used to implement out-of-process JITing from llvm-jitlink to a new llvm-jitlink-executor tool.
This patch also breaks the OrcJIT library into three parts: -- OrcTargetProcess: Contains code needed by the JIT execution process. -- OrcShared: Contains code needed by the JIT execution and compiler processes -- OrcJIT: Everything else.
This break-up allows JIT executor processes to link against OrcTargetProcess and OrcShared only, without having to link in all of OrcJIT. Clients executing JIT'd code in-process should start linking against OrcTargetProcess as well as OrcJIT.
In the near future these changes will enable: -- Removal of the OrcRemoteTargetClient/OrcRemoteTargetServer class templates which provided similar functionality in OrcV1. -- Restoration of Chapter 5 of the Building-A-JIT tutorial series, which will serve as a simple usage example for these APIs. -- Implementation of lazy, cross-target compilation in lli's -jit-kind=orc-lazy mode.
show more ...
|