[Orc][LLJIT] Use JITLink on RISC-V

RuntimeDyld does not support RISC-V, so it makes sense to enable
JITLink by default. This also makes relocations work without support
for a large code model.

Diff

[Orc][LLJIT] Use JITLink on RISC-V

RuntimeDyld does not support RISC-V, so it makes sense to enable
JITLink by default. This also makes relocations work without support
for a large code model.

Differential Revision: https://reviews.llvm.org/D129092

show more ...

[ORC][LLJIT] Define atexit symbol in GenericLLVMIRPlatformSupport.

Define atexit symbol in GenericLLVMIRPlatformSupport so that it doesn't need to be defined by user.

On windows, llvm codegen emits

[ORC][LLJIT] Define atexit symbol in GenericLLVMIRPlatformSupport.

Define atexit symbol in GenericLLVMIRPlatformSupport so that it doesn't need to be defined by user.

On windows, llvm codegen emits atexit runtime calls to support global deinitializers as there is no lower function like cxa_atexit as in Itanium C++ ABI. ORC JIT user had to define custom atexit symbol manually. This was a hassle as it has to deal with dso_handle and cxa_atexit internals of LLJIT. If client didn't provide atexit definition, the default behaviour is just linking with host atexit function which is destined to fail as it calls dtors when the host program exits. This is after jit instances and buffers are freed, so users would see weird access violation exception from the uknown location. (in console application, the debugger thinks exception happened in scrt_common_main_seh)

This is a hack that has some caveats. (e.g. memory address is not identical) But, it's better than the situation described in the above. Ultimately, we will move on to ORC runtime that is able to solve the memory address issue properly.

Reviewed By: sgraenitz

Differential Revision: https://reviews.llvm.org/D128037

show more ...

Use llvm::less_second (NFC)

[ORC] Fix sorting of contructors by priority

The code was incorrectly sorting by the function address.

Differential Revision: https://reviews.llvm.org/D123311

[ORC] Return ExecutorAddrs rather than JITEvaluatedSymbols from LLJIT::lookup.

Clients don't care about linkage, and ExecutorAddr is much more ergonomic.

[llvm] Use = default (NFC)

[ORC] Fix another missing std::move from 9eb4939b862.

[ORC] Fix missing std::move from 9eb4939b862.

[ORC] Allow JITDylib::getDFSLinkOrder and friends to fail for defunct JITDylibs.

Calls to JITDylib's getDFSLinkOrder and getReverseDFSLinkOrder methods (both
static an non-static versions) are now v

[ORC] Allow JITDylib::getDFSLinkOrder and friends to fail for defunct JITDylibs.

Calls to JITDylib's getDFSLinkOrder and getReverseDFSLinkOrder methods (both
static an non-static versions) are now valid to make on defunct JITDylibs, but
will return an error if any JITDylib in the link order is defunct.

This means that platforms can safely lookup link orders by name in response to
jit-dlopen calls from the ORC runtime, even if the call names a defunct
JITDylib -- the call will just fail with an error.

show more ...

[ORC] Add Platform::teardownJITDylib method.

This is a counterpart to Platform::setupJITDylib, and is called when JITDylib
instances are removed (via ExecutionSession::removeJITDylib).

Upcoming Mac

[ORC] Add Platform::teardownJITDylib method.

This is a counterpart to Platform::setupJITDylib, and is called when JITDylib
instances are removed (via ExecutionSession::removeJITDylib).

Upcoming MachOPlatform patches will use this to clear per-JITDylib data when
JITDylibs are removed.

show more ...

[Orc] Fix global variable destructor function support when --jit-kind=orc-lazy

The bug was reported here https://bugs.llvm.org/show_bug.cgi?id=52030

This patch follows the idea that @lhames comment

[Orc] Fix global variable destructor function support when --jit-kind=orc-lazy

The bug was reported here https://bugs.llvm.org/show_bug.cgi?id=52030

This patch follows the idea that @lhames commented in the above webpage.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D110990

show more ...

[ORC] Require ExecutorProcessControl when constructing an ExecutionSession.

Wrapper function call and dispatch handler helpers are moved to
ExecutionSession, and existing EPC-based tools are re-writ

[ORC] Require ExecutorProcessControl when constructing an ExecutionSession.

Wrapper function call and dispatch handler helpers are moved to
ExecutionSession, and existing EPC-based tools are re-written to take an
ExecutionSession argument instead.

Requiring an ExecutorProcessControl instance simplifies existing EPC based
utilities (which only need to take an ES now), and should encourage more
utilities to use the EPC interface. It also simplifies process termination,
since the session can automatically call ExecutorProcessControl::disconnect
(previously this had to be done manually, and carefully ordered with the
rest of JIT tear-down to work correctly).

show more ...

[ORC] Remove LLVM-side MachO Platform runtime support.

Support for this functionality is moving to the ORC runtime.

[ORC] Rename TargetProcessControl to ExecutorProcessControl. NFC.

This is a first step towards consistently using the term 'executor' for the
process that executes JIT'd code. I've opted for 'execut

[ORC] Rename TargetProcessControl to ExecutorProcessControl. NFC.

This is a first step towards consistently using the term 'executor' for the
process that executes JIT'd code. I've opted for 'executor' as the preferred
term over 'target' as target is already heavily overloaded ("the target
machine for the executor" is much clearer than "the target machine for the
target").

show more ...

[ORC] Generalize materialization dispatch to task dispatch.

Generalizing this API allows work to be distributed more evenly. In particular,
query callbacks can now be dispatched (rather than running

[ORC] Generalize materialization dispatch to task dispatch.

Generalizing this API allows work to be distributed more evenly. In particular,
query callbacks can now be dispatched (rather than running immediately on the
thread that satisfied the query). This avoids the pathalogical case where an
operation on one thread satisfies many queries simultaneously, causing large
amounts of work to be run on that thread while other threads potentially sit
idle.

show more ...

[lli] Add option -lljit-platform=Inactive to disable platform support explicitly

This option tells LLJIT to disable platform support explicitly: JITDylibs aren't scanned for special init/deinit symb

[lli] Add option -lljit-platform=Inactive to disable platform support explicitly

This option tells LLJIT to disable platform support explicitly: JITDylibs aren't scanned for special init/deinit symbols and no runtime API interposes are injected.
It's useful in two cases: for platforms that don't have such requirements and platforms for which we have no explicit support yet and that don't work well with the generic IR platform.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D99416

show more ...

[Orc] Rename local variable to avoid confusion with equally-named class member (NFC)

[ORC] Print CPU feature string in JITTargetMachineBuilder debugging output.

[ORC] Fix debug logging message.

[ORC] Move OrcError.h to include/llvm/ExecutionEngine/Orc/Shared.

OrcShared is the correct home for this header since Orc was split in
1d0676b54c4. (It should have been moved in that commit, but was

[ORC] Move OrcError.h to include/llvm/ExecutionEngine/Orc/Shared.

OrcShared is the correct home for this header since Orc was split in
1d0676b54c4. (It should have been moved in that commit, but was overlooked).

show more ...

[Orc] Allow LLJITBuilder's CreateObjectLinkingLayer to return errors

It can be useful for an ObjectLinkingLayerCreator to allow callee errors to get propagated to the builder. Specifically, this is

[Orc] Allow LLJITBuilder's CreateObjectLinkingLayer to return errors

It can be useful for an ObjectLinkingLayerCreator to allow callee errors to get propagated to the builder. Specifically, this is the case when the ObjectLayer uses the EHFrameRegistrationPlugin, because it requires a TPCEHFrameRegistrar and instantiation for it may fail (e.g. if the required registration symbols are missing in the target process).

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D94690

show more ...

[Orc][NFC] Turn LLJIT member ObjTransformLayer into unique_ptr

All other layers in LLJIT are stored as unique_ptr's already. At this point, it is not strictly necessary for ObjTransformLayer, but it

[Orc][NFC] Turn LLJIT member ObjTransformLayer into unique_ptr

All other layers in LLJIT are stored as unique_ptr's already. At this point, it is not strictly necessary for ObjTransformLayer, but it makes a follow-up change more straightforward.

Reviewed By: lhames

Differential Revision: https://reviews.llvm.org/D94689

show more ...

[ORC] Add basic ResourceTracker support to the OrcV2 C Bindings.

Based on a patch by Andres Freund. Thanks Andres!

[ORC] Add support for resource tracking/removal (removable code).

This patch introduces new APIs to support resource tracking and removal in Orc.
It is intended as a thread-safe generalization of th

[ORC] Add support for resource tracking/removal (removable code).

This patch introduces new APIs to support resource tracking and removal in Orc.
It is intended as a thread-safe generalization of the removeModule concept from
OrcV1.

Clients can now create ResourceTracker objects (using
JITDylib::createResourceTracker) to track resources for each MaterializationUnit
(code, data, aliases, absolute symbols, etc.) added to the JIT. Every
MaterializationUnit will be associated with a ResourceTracker, and
ResourceTrackers can be re-used for multiple MaterializationUnits. Each JITDylib
has a default ResourceTracker that will be used for MaterializationUnits added
to that JITDylib if no ResourceTracker is explicitly specified.

Two operations can be performed on ResourceTrackers: transferTo and remove. The
transferTo operation transfers tracking of the resources to a different
ResourceTracker object, allowing ResourceTrackers to be merged to reduce
administrative overhead (the source tracker is invalidated in the process). The
remove operation removes all resources associated with a ResourceTracker,
including any symbols defined by MaterializationUnits associated with the
tracker, and also invalidates the tracker. These operations are thread safe, and
should work regardless of the the state of the MaterializationUnits. In the case
of resource transfer any existing resources associated with the source tracker
will be transferred to the destination tracker, and all future resources for
those units will be automatically associated with the destination tracker. In
the case of resource removal all already-allocated resources will be
deallocated, any if any program representations associated with the tracker have
not been compiled yet they will be destroyed. If any program representations are
currently being compiled then they will be prevented from completing: their
MaterializationResponsibility will return errors on any attempt to update the
JIT state.

Clients (usually Layer writers) wishing to track resources can implement the
ResourceManager API to receive notifications when ResourceTrackers are
transferred or removed. The MaterializationResponsibility::withResourceKeyDo
method can be used to create associations between the key for a ResourceTracker
and an allocated resource in a thread-safe way.

RTDyldObjectLinkingLayer and ObjectLinkingLayer are updated to use the
ResourceManager API to enable tracking and removal of memory allocated by the
JIT linker.

The new JITDylib::clear method can be used to trigger removal of every
ResourceTracker associated with the JITDylib (note that this will only
remove resources for the JITDylib, it does not run static destructors).

This patch includes unit tests showing basic usage. A follow-up patch will
update the Kaleidoscope and BuildingAJIT tutorial series to OrcV2 and will
use this API to release code associated with anonymous expressions.

show more ...

Re-apply "[ORC] Make MaterializationResponsibility immovable..." with fixes.

Re-applies c74900ca672 with fixes for the ThinLtoJIT example.