Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...