RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 18:54:02 +01:00
Code Issues Projects Releases Wiki Activity
f7d625e31a
llvm-mirror/lib/ExecutionEngine/Orc/CMakeLists.txt

61 lines
1.1 KiB
CMake
Raw Normal View History

[cmake] Explicitly mark libraries defined in lib/ as "Component Libraries" Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
2019-11-14 06:39:58 +01:00
add_llvm_component_library(LLVMOrcJIT
[ORC] Add an initial implementation of a replacement CompileOnDemandLayer. CompileOnDemandLayer2 is a replacement for CompileOnDemandLayer built on the ORC Core APIs. Functions in added modules are extracted and compiled lazily. CompileOnDemandLayer2 supports multithreaded JIT'd code, and compilation on multiple threads. llvm-svn: 334967
2018-06-18 20:01:43 +02:00
CompileOnDemandLayer.cpp
[ORC] Move SimpleCompiler/ConcurrentIRCompiler definitions into a .cpp file. SimpleCompiler is no longer templated, so there's no reason for this code to be in a header any more. llvm-svn: 359626
2019-05-01 00:42:01 +02:00
CompileUtils.cpp
[ORC] Re-apply r321838 again with a workaround for a bug present in the libcxx version being used on some of the green dragon builders (plus a clang-format). Workaround: AsynchronousSymbolQuery and VSO want to work with JITEvaluatedSymbols anyway, so just use them (instead of JITSymbol, which happens to tickle the bug). The libcxx bug being worked around was fixed in r276003, and there are plans to update the offending builders. llvm-svn: 322140
2018-01-10 01:09:38 +01:00
Core.cpp
[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
2021-03-02 12:37:48 +01:00
DebugObjectManagerPlugin.cpp
[ORC] Add a utility to support dumping JIT'd objects to disk for debugging. Adds a DumpObjects utility that can be used to dump JIT'd objects to disk. Instances of DebugObjects may be used by ObjectTransformLayer as no-op transforms. This patch also adds an ObjectTransformLayer to LLJIT and an example of how to use this utility to dump JIT'd objects in LLJIT.
2019-11-15 00:58:21 +01:00
DebugUtils.cpp
[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").
2021-07-01 03:53:18 +02:00
EPCDynamicLibrarySearchGenerator.cpp
EPCDebugObjectRegistrar.cpp
EPCEHFrameRegistrar.cpp
EPCIndirectionUtils.cpp
Fix line endings (NFC) I inadvertently checked these in with Windows-style line endings in r240288. llvm-svn: 240340
2015-06-22 23:37:34 +02:00
ExecutionUtils.cpp
IndirectionUtils.cpp
[LKH] Add a new IRCompileLayer. llvm-svn: 333127
2018-05-23 23:27:01 +02:00
IRCompileLayer.cpp
[LKH] Add a new IRTransformLayer. llvm-svn: 333129
2018-05-23 23:27:07 +02:00
IRTransformLayer.cpp
[ORC] Extract and tidy up JITTargetMachineBuilder, add unit test. (1) Adds comments for the API. (2) Removes the setArch method: This is redundant: the setArchStr method on the triple should be used instead. (3) Turns EmulatedTLS on by default. This matches EngineBuilder's behavior. llvm-svn: 343423
2018-09-30 21:12:23 +02:00
JITTargetMachineBuilder.cpp
[ORC] Add a "lazy call-through" utility based on the same underlying trampoline implementation as lazy compile callbacks, and a "lazy re-exports" utility that builds lazy call-throughs. Lazy call-throughs are similar to lazy compile callbacks (and are based on the same underlying state saving/restoring trampolines) but resolve their targets by performing a standard ORC lookup rather than invoking a user supplied compiler callback. This allows them to inherit the thread-safety of ORC lookups while blocking only the calling thread (whereas compile callbacks also block one compile thread). Lazy re-exports provide a simple way of building lazy call-throughs. Unlike a regular re-export, a lazy re-export generates a new address (a stub entry point) that will act like the re-exported symbol when called. The first call via a lazy re-export will trigger compilation of the re-exported symbol before calling through to it. llvm-svn: 343061
2018-09-26 06:18:30 +02:00
LazyReexports.cpp
[ORC] Add IRLayer and ObjectLayer interfaces and related MaterializationUnits. llvm-svn: 332896
2018-05-21 23:11:13 +02:00
Layer.cpp
[ORC] Add LLJIT and LLLazyJIT, and replace OrcLazyJIT in LLI with LLLazyJIT. LLJIT is a prefabricated ORC based JIT class that is meant to be the go-to replacement for MCJIT. Unlike OrcMCJITReplacement (which will continue to be supported) it is not API or bug-for-bug compatible, but targets the same use cases: Simple, non-lazy compilation and execution of LLVM IR. LLLazyJIT extends LLJIT with support for function-at-a-time lazy compilation, similar to what was provided by LLVM's original (now long deprecated) JIT APIs. This commit also contains some simple utility classes (CtorDtorRunner2, LocalCXXRuntimeOverrides2, JITTargetMachineBuilder) to support LLJIT and LLLazyJIT. Both of these classes are works in progress. Feedback from JIT clients is very welcome! llvm-svn: 335670
2018-06-26 23:35:48 +02:00
LLJIT.cpp
[ORC] Add generic initializer/deinitializer support. Initializers and deinitializers are used to implement C++ static constructors and destructors, runtime registration for some languages (e.g. with the Objective-C runtime for Objective-C/C++ code) and other tasks that would typically be performed when a shared-object/dylib is loaded or unloaded by a statically compiled program. MCJIT and ORC have historically provided limited support for discovering and running initializers/deinitializers by scanning the llvm.global_ctors and llvm.global_dtors variables and recording the functions to be run. This approach suffers from several drawbacks: (1) It only works for IR inputs, not for object files (including cached JIT'd objects). (2) It only works for initializers described by llvm.global_ctors and llvm.global_dtors, however not all initializers are described in this way (Objective-C, for example, describes initializers via specially named metadata sections). (3) To make the initializer/deinitializer functions described by llvm.global_ctors and llvm.global_dtors searchable they must be promoted to extern linkage, polluting the JIT symbol table (extra care must be taken to ensure this promotion does not result in symbol name clashes). This patch introduces several interdependent changes to ORCv2 to support the construction of new initialization schemes, and includes an implementation of a backwards-compatible llvm.global_ctor/llvm.global_dtor scanning scheme, and a MachO specific scheme that handles Objective-C runtime registration (if the Objective-C runtime is available) enabling execution of LLVM IR compiled from Objective-C and Swift. The major changes included in this patch are: (1) The MaterializationUnit and MaterializationResponsibility classes are extended to describe an optional "initializer" symbol for the module (see the getInitializerSymbol method on each class). The presence or absence of this symbol indicates whether the module contains any initializers or deinitializers. The initializer symbol otherwise behaves like any other: searching for it triggers materialization. (2) A new Platform interface is introduced in llvm/ExecutionEngine/Orc/Core.h which provides the following callback interface: - Error setupJITDylib(JITDylib &JD): Can be used to install standard symbols in JITDylibs upon creation. E.g. __dso_handle. - Error notifyAdding(JITDylib &JD, const MaterializationUnit &MU): Generally used to record initializer symbols. - Error notifyRemoving(JITDylib &JD, VModuleKey K): Used to notify a platform that a module is being removed. Platform implementations can use these callbacks to track outstanding initializers and implement a platform-specific approach for executing them. For example, the MachOPlatform installs a plugin in the JIT linker to scan for both __mod_inits sections (for C++ static constructors) and ObjC metadata sections. If discovered, these are processed in the usual platform order: Objective-C registration is carried out first, then static initializers are executed, ensuring that calls to Objective-C from static initializers will be safe. This patch updates LLJIT to use the new scheme for initialization. Two LLJIT::PlatformSupport classes are implemented: A GenericIR platform and a MachO platform. The GenericIR platform implements a modified version of the previous llvm.global-ctor scraping scheme to provide support for Windows and Linux. LLJIT's MachO platform uses the MachOPlatform class to provide MachO specific initialization as described above. Reviewers: sgraenitz, dblaikie Subscribers: mgorny, hiraditya, mgrang, ributzka, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D74300
2019-12-16 11:50:40 +01:00
MachOPlatform.cpp
Mangling.cpp
Initial implementation of JITLink - A replacement for RuntimeDyld. Summary: JITLink is a jit-linker that performs the same high-level task as RuntimeDyld: it parses relocatable object files and makes their contents runnable in a target process. JITLink aims to improve on RuntimeDyld in several ways: (1) A clear design intended to maximize code-sharing while minimizing coupling. RuntimeDyld has been developed in an ad-hoc fashion for a number of years and this had led to intermingling of code for multiple architectures (e.g. in RuntimeDyldELF::processRelocationRef) in a way that makes the code more difficult to read, reason about, extend. JITLink is designed to isolate format and architecture specific code, while still sharing generic code. (2) Support for native code models. RuntimeDyld required the use of large code models (where calls to external functions are made indirectly via registers) for many of platforms due to its restrictive model for stub generation (one "stub" per symbol). JITLink allows arbitrary mutation of the atom graph, allowing both GOT and PLT atoms to be added naturally. (3) Native support for asynchronous linking. JITLink uses asynchronous calls for symbol resolution and finalization: these callbacks are passed a continuation function that they must call to complete the linker's work. This allows for cleaner interoperation with the new concurrent ORC JIT APIs, while still being easily implementable in synchronous style if asynchrony is not needed. To maximise sharing, the design has a hierarchy of common code: (1) Generic atom-graph data structure and algorithms (e.g. dead stripping and | memory allocation) that are intended to be shared by all architectures. | + -- (2) Shared per-format code that utilizes (1), e.g. Generic MachO to | atom-graph parsing. | + -- (3) Architecture specific code that uses (1) and (2). E.g. JITLinkerMachO_x86_64, which adds x86-64 specific relocation support to (2) to build and patch up the atom graph. To support asynchronous symbol resolution and finalization, the callbacks for these operations take continuations as arguments: using JITLinkAsyncLookupContinuation = std::function<void(Expected<AsyncLookupResult> LR)>; using JITLinkAsyncLookupFunction = std::function<void(const DenseSet<StringRef> &Symbols, JITLinkAsyncLookupContinuation LookupContinuation)>; using FinalizeContinuation = std::function<void(Error)>; virtual void finalizeAsync(FinalizeContinuation OnFinalize); In addition to its headline features, JITLink also makes other improvements: - Dead stripping support: symbols that are not used (e.g. redundant ODR definitions) are discarded, and take up no memory in the target process (In contrast, RuntimeDyld supported pointer equality for weak definitions, but the redundant definitions stayed resident in memory). - Improved exception handling support. JITLink provides a much more extensive eh-frame parser than RuntimeDyld, and is able to correctly fix up many eh-frame sections that RuntimeDyld currently (silently) fails on. - More extensive validation and error handling throughout. This initial patch supports linking MachO/x86-64 only. Work on support for other architectures and formats will happen in-tree. Differential Revision: https://reviews.llvm.org/D58704 llvm-svn: 358818
2019-04-20 19:10:34 +02:00
ObjectLinkingLayer.cpp
[LKH] Add ObjectTransformLayer2. llvm-svn: 333128
2018-05-23 23:27:06 +02:00
ObjectTransformLayer.cpp
[Orc] Rename OrcArchitectureSupport to OrcABISupport and add Win32 ABI support. This enables lazy JITing on Windows x86-64. Patch by David. Thanks David! llvm-svn: 268845
2016-05-07 05:36:38 +02:00
OrcABISupport.cpp
[Orc] Add basic OrcV2 C bindings and example. Renames the llvm/examples/LLJITExamples directory to llvm/examples/OrcV2Examples since it is becoming a home for all OrcV2 examples, not just LLJIT. See http://llvm.org/PR31103.
2020-03-14 22:16:42 +01:00
OrcV2CBindings.cpp
[LKH] Add a replacement RTDyldLayer. llvm-svn: 332918
2018-05-22 01:45:40 +02:00
RTDyldObjectLinkingLayer.cpp
Speculative Compilation [ORC] Remove Speculator Variants for Different Program Representations [ORC] Block Freq Analysis Speculative Compilation with Naive Block Frequency Add Applications to OrcSpeculation ORC v2 with Block Freq Query & Example Deleted BenchMark Programs Signed-off-by: preejackie <praveenvelliengiri@gmail.com> ORCv2 comments resolved [ORCV2] NFC ORCv2 NFC [ORCv2] Speculative compilation - CFGWalkQuery ORCv2 Adapting IRSpeculationLayer to new locking scheme llvm-svn: 367756
2019-08-03 16:42:13 +02:00
Speculation.cpp
SpeculateAnalyses.cpp
[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").
2021-07-01 03:53:18 +02:00
ExecutorProcessControl.cpp
[ORC] Add TargetProcessControl and TPCIndirectionUtils APIs. TargetProcessControl is a new API for communicating with JIT target processes. It supports memory allocation and access, and inspection of some process properties, e.g. the target proces triple and page size. Centralizing these APIs allows utilities written against TargetProcessControl to remain independent of the communication procotol with the target process (which may be direct memory access/allocation for in-process JITing, or may involve some form of IPC or RPC). An initial set of TargetProcessControl-based utilities for lazy compilation is provided by the TPCIndirectionUtils class. An initial implementation of TargetProcessControl for in-process JITing is provided by the SelfTargetProcessControl class. An example program showing how the APIs can be used is provided in llvm/examples/OrcV2Examples/LLJITWithTargetProcessControl.
2020-07-16 21:51:14 +02:00
ThreadSafeModule.cpp
Fix line endings (NFC) I inadvertently checked these in with Windows-style line endings in r240288. llvm-svn: 240340
2015-06-22 23:37:34 +02:00
ADDITIONAL_HEADER_DIRS
${LLVM_MAIN_INCLUDE_DIR}/llvm/ExecutionEngine/Orc
DEPENDS
intrinsics_gen
llvmbuildectomy - replace llvm-build by plain cmake No longer rely on an external tool to build the llvm component layout. Instead, leverage the existing `add_llvm_componentlibrary` cmake function and introduce `add_llvm_component_group` to accurately describe component behavior. These function store extra properties in the created targets. These properties are processed once all components are defined to resolve library dependencies and produce the header expected by llvm-config. Differential Revision: https://reviews.llvm.org/D90848
2020-10-09 18:41:21 +02:00
LINK_COMPONENTS
Core
ExecutionEngine
JITLink
Object
OrcShared
OrcTargetProcess
MC
Passes
RuntimeDyld
Support
Target
TransformUtils
Fix line endings (NFC) I inadvertently checked these in with Windows-style line endings in r240288. llvm-svn: 240340
2015-06-22 23:37:34 +02:00
)
[ORC] Add BitReader/BitWriter to target_link_libraries Summary: CompileOnDemandLayer.cpp uses function in these libraries, and builds with `-DSHARED_LIB=ON` fail without this. Reviewers: lhames Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D48995 llvm-svn: 336389
2018-07-05 23:23:15 +02:00
[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.
2020-11-11 01:55:24 +01:00
add_subdirectory(Shared)
add_subdirectory(TargetProcess)
Revert "[build] normalize components dependencies" This reverts commit c6ef6e1690d517b3401ea06b1fe46871eb67434d. Basically, publicly linked libraries have a different semantic than components, which link libraries privately. Differential Revision: https://reviews.llvm.org/D91461
2020-11-18 19:19:36 +01:00
target_link_libraries(LLVMOrcJIT
PRIVATE
LLVMAnalysis
LLVMBitReader
LLVMBitWriter
LLVMPasses
)
Reference in New Issue Copy Permalink