summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORC] clang-format OrcMips32 and OrcMips64 code. NFCSimon Atanasyan2018-12-231-24/+16
| | | | llvm-svn: 350022
* [ORC] Remove redundant instruction from MIPS resolver code. NFCSimon Atanasyan2018-12-231-8/+7
| | | | | | It's redundant to restore the `$a3` register twice. llvm-svn: 350021
* [ExecutionEngine] Change NotifyObjectEmitted/NotifyObjectFreed API.Lang Hames2018-12-041-2/+6
| | | | | | | | | | | | | This patch renames both methods (NotifyObjectEmitted -> notifyObjectLoaded, and NotifyObjectFreed -> notifyObjectFreed), adds an abstract "ObjectKey" (uint64_t) parameter to notifyObjectLoaded, and replaces the ObjectFile parameter for notifyObjectFreed with an ObjectKey. Using an ObjectKey to track identify events, rather than a reference to the ObjectFile, allows us to free the ObjectFile after notifyObjectLoaded is called, saving memory. https://reviews.llvm.org/D53773 llvm-svn: 348223
* [BuildingAJIT] Update chapter 2 to use the ORCv2 APIs.Lang Hames2018-11-131-1/+2
| | | | llvm-svn: 346726
* [ORC] Fix hex printing of uint64_t values.Lang Hames2018-10-312-6/+6
| | | | | | | A plain "%x" format string will drop the high 32-bits. Use the PRIx64 macro instead. llvm-svn: 345696
* ADT/STLExtras: Introduce llvm::empty; NFCMatthias Braun2018-10-311-1/+1
| | | | | | | | This is modeled after C++17 std::empty(). Differential Revision: https://reviews.llvm.org/D53909 llvm-svn: 345679
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-237-83/+113
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-237-112/+84
| | | | | | | | | | | | | | | lookup." Doesn't build on Windows. The call to 'lookup' is ambiguous. Clang and MSVC agree, anyway. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/787 C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): error C2668: 'llvm::orc::ExecutionSession::lookup': ambiguous call to overloaded function C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(823): note: could be 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(llvm::ArrayRef<llvm::orc::JITDylib *>,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\include\llvm/ExecutionEngine/Orc/Core.h(817): note: or 'llvm::Expected<llvm::JITEvaluatedSymbol> llvm::orc::ExecutionSession::lookup(const llvm::orc::JITDylibSearchList &,llvm::orc::SymbolStringPtr)' C:\b\slave\clang-x64-windows-msvc\build\llvm.src\unittests\ExecutionEngine\Orc\CoreAPIsTest.cpp(315): note: while trying to match the argument list '(initializer list, llvm::orc::SymbolStringPtr)' llvm-svn: 345078
* [ORC] Change how non-exported symbols are matched during lookup.Lang Hames2018-10-237-84/+112
| | | | | | | | | | | | | | | | | In the new scheme the client passes a list of (JITDylib&, bool) pairs, rather than a list of JITDylibs. For each JITDylib the boolean indicates whether or not to match against non-exported symbols (true means that they should be found, false means that they should not). The MatchNonExportedInJD and MatchNonExported parameters on lookup are removed. The new scheme is more flexible, and easier to understand. This patch also updates JITDylib search orders to be lists of (JITDylib&, bool) pairs to match the new lookup scheme. Error handling is also plumbed through the LLJIT class to allow regression tests to fail predictably when a lookup from a lazy call-through fails. llvm-svn: 345077
* [ORC] Show JITDylib search order in JITDylib::dump.Lang Hames2018-10-231-0/+4
| | | | | | This can be helpful in debugging search-order related failures. llvm-svn: 344994
* [ORC] Dump flags for JITDylib symbol table entries.Lang Hames2018-10-231-2/+2
| | | | | | This can help when debugging flag-specific symbol table issues. llvm-svn: 344993
* [ORC] Guard access to the MemMgrs vector in RTDyldObjectLinkingLayer.Lang Hames2018-10-221-3/+10
| | | | | | | | | Otherwise we can end up with a data-race when linking concurrently. This should fix an intermittent failure in the multiple-compile-threads-basic.ll testcase. llvm-svn: 344956
* [ORC] Make the VModuleKey optional, propagate it via MaterializationUnit andLang Hames2018-10-1610-71/+70
| | | | | | | | | | | | | | | | | | | | | | MaterializationResponsibility. VModuleKeys are intended to enable selective removal of modules from a JIT session, however for a wide variety of use cases selective removal is not needed and introduces unnecessary overhead. As of this commit, the default constructed VModuleKey value is reserved as a "do not track" value, and becomes the default when adding a new module to the JIT. This commit also changes the propagation of VModuleKeys. They were passed alongside the MaterializationResponsibity instance in XXLayer::emit methods, but are now propagated as part of the MaterializationResponsibility instance itself (and as part of MaterializationUnit when stored in a JITDylib). Associating VModuleKeys with MaterializationUnits in this way should allow for a thread-safe module removal mechanism in the future, even when a module is in the process of being compiled, by having the MaterializationResponsibility object check in on its VModuleKey's state before commiting its results to the JITDylib. llvm-svn: 344643
* [ORC] Rename ORC layers to make the "new" ORC layers the default.Lang Hames2018-10-1510-44/+44
| | | | | | | | | | | | | This commit adds a 'Legacy' prefix to old ORC layers and utilities, and removes the '2' suffix from the new ORC layers. If you wish to continue using the old ORC layers you will need to add a 'Legacy' prefix to your classes. If you were already using the new ORC layers you will need to drop the '2' suffix. The legacy layers will remain in-tree until the new layers reach feature parity with them. This will involve adding support for removing code from the new layers, and ensuring that performance is comperable. llvm-svn: 344572
* [ORC] Rename MultiThreadedSimpleCompiler to ConcurrentIRCompiler.Lang Hames2018-10-151-1/+1
| | | | | | | | | | | The new name is a better fit: This class does not actually spawn any new threads for compilation, it is just safe to call from multiple threads concurrently. The "Simple" part of the name did not convey much either, so it was dropped. llvm-svn: 344567
* [ORC] Switch to DenseMap/DenseSet for ORC symbol map/set types.Lang Hames2018-10-152-29/+38
| | | | llvm-svn: 344565
* [ORC] Simplify naming for JITDylib definition generators.Lang Hames2018-10-152-33/+36
| | | | | | | | | Renames: JITDylib's setFallbackDefinitionGenerator method to setGenerator. DynamicLibraryFallbackGenerator class to DynamicLibrarySearchGenerator. ReexportsFallbackDefinitionGenerator to ReexportsGenerator. llvm-svn: 344489
* [ORC] During lookup, do not match against hidden symbols in other JITDylibs.Lang Hames2018-10-136-46/+64
| | | | | | | | | | | | This adds two arguments to the main ExecutionSession::lookup method: MatchNonExportedInJD, and MatchNonExported. These control whether and where hidden symbols should be matched when searching a list of JITDylibs. A similar effect could have been achieved by filtering search results, but this would have involved materializing symbol definitions (since materialization is triggered on lookup) only to throw the results away, among other issues. llvm-svn: 344467
* [ORC] Promote and rename private symbols inside the CompileOnDemand layer,Lang Hames2018-10-094-8/+38
| | | | | | | | | | | | | | | rather than require them to have been promoted before being passed in. Dropping this precondition is better for layer composition (CompileOnDemandLayer was the only one that placed pre-conditions on the modules that could be added). It also means that the promoted private symbols do not show up in the target JITDylib's symbol table. Instead, they are confined to the hidden implementation dylib that contains the actual definitions. For the 403.gcc testcase this cut down the public symbol table size from ~15,000 symbols to ~4000, substantially reducing symbol dependence tracking costs. llvm-svn: 344078
* [ORC] Add a 'remove' method to JITDylib to remove symbols.Lang Hames2018-10-061-0/+68
| | | | | | | | Symbols can be removed provided that all are present in the JITDylib and none are currently in the materializing state. On success all requested symbols are removed. On failure an error is returned and no symbols are removed. llvm-svn: 343928
* [ORC] Pass symbol name to discard by const reference.Lang Hames2018-10-065-7/+8
| | | | | | This saves some unnecessary atomic ref-counting operations. llvm-svn: 343927
* [ORC] Pass Symbols to ExecutionSession::lookup by value, potentially saving aLang Hames2018-10-011-2/+2
| | | | | | copy. llvm-svn: 343442
* [ORC] Add convenience methods for creating DynamicLibraryFallbackGenerators forLang Hames2018-10-011-0/+9
| | | | | | | | libraries on disk, and for the current process. Avoids more boilerplate during JIT construction. llvm-svn: 343430
* [ORC] Add an 'intern' method to ExecutionEngine for interning symbol names.Lang Hames2018-09-306-11/+10
| | | | | | | This cuts down on boilerplate by reducing 'ES.getSymbolStringPool().intern(...)' to 'ES.intern(...)'. llvm-svn: 343427
* [ORC] Extract and tidy up JITTargetMachineBuilder, add unit test.Lang Hames2018-09-303-39/+56
| | | | | | | | | | | (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
* [ORC] Add partitioning support to CompileOnDemandLayer2.Lang Hames2018-09-293-160/+180
| | | | | | | | | | | | | CompileOnDemandLayer2 now supports user-supplied partition functions (the original CompileOnDemandLayer already supported these). Partition functions are called with the list of requested global values (i.e. global values that currently have queries waiting on them) and have an opportunity to select extra global values to materialize at the same time. Also adds testing infrastructure for the new feature to lli. llvm-svn: 343396
* [ORC] Clear SymbolToDefinitionMap when materializing a MaterializationUnit.Lang Hames2018-09-291-0/+5
| | | | | | | The map is inaccessible at this point, so we may as well reclaim the memory early. llvm-svn: 343395
* [ORC] Make MaterializationResponsibility::getRequestedSymbols() const.Lang Hames2018-09-281-3/+4
| | | | | | | | This makes it available for use in IRTransformLayer2::TransformFunction instances (since a const MaterializationResponsibility& parameter was added in r343365). llvm-svn: 343367
* [ORC] Add more utilities to aid debugging output.Lang Hames2018-09-281-1/+1
| | | | | | | | | | | | | (1) A const accessor for the LLVMContext held by a ThreadSafeContext. (2) A const accessor for the ThreadSafeModules held by an IRMaterializationUnit. (3) A const MaterializationResponsibility reference to IRTransformLayer2's transform function. This makes IRTransformLayer2 useful for JIT debugging (since it can inspect JIT state through the responsibility argument) as well as program transformations. llvm-svn: 343365
* [ORC] Narrow a cast: the block guarded by the condition only handlesLang Hames2018-09-281-1/+1
| | | | | | GlobalVariables, not all GlobalValues. llvm-svn: 343358
* [ORC] Remove some dead code.Lang Hames2018-09-281-20/+0
| | | | llvm-svn: 343327
* [ORC] Improve debugging output for ORC.Lang Hames2018-09-284-44/+191
| | | | | | | | | | | | (1) Print debugging output under a session lock to avoid garbled messages when compiling on multiple threads. (2) Name MaterializationUnits, add an ostream operator for them, and so they can be easily referenced in debugging output, and have that ostream operator optionally print code/data/hidden symbols provided by that materialization unit based on command line options. llvm-svn: 343323
* [ORC] clang-format the ThreadSafeModule code.Lang Hames2018-09-281-4/+4
| | | | | | Evidently I forgot to do this before committing r343055. llvm-svn: 343288
* [ORC] Add definition for IRLayer::setCloneToNewContextOnEmit, use it to set theLang Hames2018-09-271-18/+24
| | | | | | | | | | | flag to true in LLJIT when running in multithreaded mode. The IRLayer::setCloneToNewContextOnEmit method sets a flag within the IRLayer that causes modules added to that layer to be moved to a new context (by serializing to/from a memory buffer) when they are emitted. This allows modules that were all loaded on the same context to be compiled in parallel. llvm-svn: 343266
* [ORC] Coalesce all of ORC's symbol renaming / linkage-promotion utilities intoLang Hames2018-09-272-50/+16
| | | | | | | | | | | | one SymbolLinkagePromoter utility. SymbolLinkagePromoter renames anonymous and private symbols, and bumps all linkages to at least global/hidden-visibility. Modules whose symbols have been promoted by this utility can be decomposed into sub-modules without introducing link errors. This is used by the CompileOnDemandLayer to extract single-function modules for lazy compilation. llvm-svn: 343257
* [ORC] Use ExecutionSession's pre-constructed main JITDylib in LLJIT.Lang Hames2018-09-271-2/+2
| | | | | | | As of r342086 ExecutionSession automatically creates a 'main' JITDylib, so there is no need for LLJIT to create its own. llvm-svn: 343167
* Reapply r343058 with a fix for -DLLVM_ENABLE_THREADS=OFF.Lang Hames2018-09-261-9/+84
| | | | | | | | | Modifies lit to add a 'thread_support' feature that can be used in lit test REQUIRES clauses. The thread_support flag is set if -DLLVM_ENABLE_THREADS=ON and unset if -DLLVM_ENABLE_THREADS=OFF. The lit flag is used to disable the multiple-compile-threads-basic.ll testcase when threading is disabled. llvm-svn: 343122
* Revert r343058 "[ORC] Add support for multithreaded compiles to LLJIT and ↵Hans Wennborg2018-09-261-84/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLLazyJIT." This doesn't work well in builds configured with LLVM_ENABLE_THREADS=OFF, causing the following assert when running ExecutionEngine/OrcLazy/multiple-compile-threads-basic.ll: lib/ExecutionEngine/Orc/Core.cpp:1748: Expected<llvm::JITEvaluatedSymbol> llvm::orc::lookup(const llvm::orc::JITDylibList &, llvm::orc::SymbolStringPtr): Assertion `ResultMap->size() == 1 && "Unexpected number of results"' failed. > LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads > arguments. If this is non-zero then a thread-pool will be created with the > given number of threads, and compile tasks will be dispatched to the thread > pool. > > To enable testing of this feature, two new flags are added to lli: > > (1) -compile-threads=N (N = 0 by default) controls the number of compile threads > to use. > > (2) -thread-entry can be used to execute code on additional threads. For each > -thread-entry argument supplied (multiple are allowed) a new thread will be > created and the given symbol called. These additional thread entry points are > called after static constructors are run, but before main. llvm-svn: 343099
* [ORC] Update CompileOnDemandLayer2 to use the new lazyReexports mechanismLang Hames2018-09-263-80/+54
| | | | | | | | | | | | for lazy compilation, rather than a callback manager. The new mechanism does not block compile threads, and does not require function bodies to be renamed. Future modifications should allow laziness on a per-module basis to work without any modification of the input module. llvm-svn: 343065
* [ORC] Add a "lazy call-through" utility based on the same underlying trampolineLang Hames2018-09-262-0/+205
| | | | | | | | | | | | | | | | | | | | 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
* [ORC] Refactor trampoline pool management out of JITCompileCallbackManager.Lang Hames2018-09-263-48/+91
| | | | | | | | | | | | | | | | | This will allow trampoline pools to be re-used for a new lazy-reexport utility that generates looks up function bodies using the standard symbol lookup process (rather than using a user provided compile function). This new utility provides the same capabilities (since MaterializationUnits already allow user supplied compile functions to be run) as JITCompileCallbackManager, but can use the new asynchronous lookup functions to avoid blocking a compile thread. This patch also updates createLocalCompileCallbackManager to return an error if a callback manager can not be created, and updates clients of that API to account for the change. Finally, the OrcCBindingsStack is updates so that if a callback manager is not available for the target platform a valid stack (without support for lazy compilation) can still be constructed. llvm-svn: 343059
* [ORC] Add support for multithreaded compiles to LLJIT and LLLazyJIT.Lang Hames2018-09-261-8/+82
| | | | | | | | | | | | | | | | | | | LLJIT and LLLazyJIT can now be constructed with an optional NumCompileThreads arguments. If this is non-zero then a thread-pool will be created with the given number of threads, and compile tasks will be dispatched to the thread pool. To enable testing of this feature, two new flags are added to lli: (1) -compile-threads=N (N = 0 by default) controls the number of compile threads to use. (2) -thread-entry can be used to execute code on additional threads. For each -thread-entry argument supplied (multiple are allowed) a new thread will be created and the given symbol called. These additional thread entry points are called after static constructors are run, but before main. llvm-svn: 343058
* [ORC] Add ThreadSafeModule and ThreadSafeContext wrappers to support concurrentLang Hames2018-09-267-114/+156
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compilation of IR in the JIT. ThreadSafeContext is a pair of an LLVMContext and a mutex that can be used to lock that context when it needs to be accessed from multiple threads. ThreadSafeModule is a pair of a unique_ptr<Module> and a shared_ptr<ThreadSafeContext>. This allows the lifetime of a ThreadSafeContext to be managed automatically in terms of the ThreadSafeModules that refer to it: Once all modules using a ThreadSafeContext are destructed, and providing the client has not held on to a copy of shared context pointer, the context will be automatically destructed. This scheme is necessary due to the following constraits: (1) We need multiple contexts for multithreaded compilation (at least one per compile thread plus one to store any IR not currently being compiled, though one context per module is simpler). (2) We need to free contexts that are no longer being used so that the JIT does not leak memory over time. (3) Module lifetimes are not predictable (modules are compiled as needed depending on the flow of JIT'd code) so there is no single point where contexts could be reclaimed. JIT clients not using concurrency can safely use one ThreadSafeContext for all ThreadSafeModules. JIT clients who want to be able to compile concurrently should use a different ThreadSafeContext for each module, or call setCloneToNewContextOnEmit on their top-level IRLayer. The former reduces compile latency (since no clone step is needed) at the cost of additional memory overhead for uncompiled modules (as every uncompiled module will duplicate the LLVM types, constants and metadata that have been shared). llvm-svn: 343055
* [ORC] Add an asynchronous jit-link function, jitLinkForORC, to RuntimeDyld andLang Hames2018-09-251-56/+88
| | | | | | | | | | | | | | | | | switch RTDyldObjectLinkingLayer2 to use it. RuntimeDyld::loadObject is currently a blocking operation. This means that any JIT'd code whose call-graph contains an embedded complete K graph will require at least K threads to link, which precludes the use of a fixed sized thread pool for concurrent JITing of arbitrary code (whatever K the thread-pool is set at, any code with a K+1 complete subgraph will deadlock at JIT-link time). To address this issue, this commmit introduces a function called jitLinkForORC that uses continuation-passing style to pass the fix-up and finalization steps to the asynchronous symbol resolver interface so that linking can be performed without blocking. llvm-svn: 343043
* [ORC] Reapply r342939 with a fix for MSVC's promise/future restrictions.Lang Hames2018-09-252-34/+46
| | | | llvm-svn: 343012
* Revert "[ORC] Switch to asynchronous resolution in JITSymbolResolver."Lang Hames2018-09-252-46/+34
| | | | | | | | | This reverts commit r342939. MSVC's promise/future implementation does not like types that are not default constructible. Reverting while I figure out a solution. llvm-svn: 342941
* [ORC] Switch to asynchronous resolution in JITSymbolResolver.Lang Hames2018-09-252-34/+46
| | | | | | | | | | | | | | | | | | | Asynchronous resolution (where the caller receives a callback once the requested set of symbols are resolved) is a core part of the new concurrent ORC APIs. This change extends the asynchronous resolution model down to RuntimeDyld, which is necessary to prevent deadlocks when compiling/linking on a fixed number of threads: If RuntimeDyld's linking process were a blocking operation, then any complete K-graph in a program will require at least K threads to link in the worst case, as each thread would block waiting for all the others to complete. Using callbacks instead allows the work to be passed between dependent threads until it is complete. For backwards compatibility, all existing RuntimeDyld functions will continue to operate in blocking mode as before. This change will enable the introduction of a new async finalization process in a subsequent patch to enable asynchronous JIT linking. llvm-svn: 342939
* [ORC] Add some debugging output to Core.h/Core.cppLang Hames2018-09-231-0/+4
| | | | | | Core now logs when materialization units are dispatched or return to JITDylibs. llvm-svn: 342853
* [ORC] Update ORC C bindings to use the new llvm::Error C API.Lang Hames2018-09-232-145/+138
| | | | | | | | | This replaces instances of the LLVMOrcErrorCode type with LLVMErrorRef, simplifying the implementation of the OrcCBindingsStack class and ORC C API bindings and making it possible to return arbitrary (wrapped) llvm::Errors. llvm-svn: 342828
* [ORC] Merge ExecutionSessionBase with ExecutionSession by moving a couple ofLang Hames2018-09-122-365/+385
| | | | | | | | | | template methods in JITDylib out-of-line. This also splits JITDylib::define into a pair of template methods, one taking an lvalue reference and the other an rvalue reference. This simplifies the templates at the cost of a small amount of code duplication. llvm-svn: 342087
OpenPOWER on IntegriCloud