summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORC] Pass symbol name to discard by const reference.Lang Hames2018-10-061-1/+2
| | | | | | This saves some unnecessary atomic ref-counting operations. llvm-svn: 343927
* [ORC] Add an 'intern' method to ExecutionEngine for interning symbol names.Lang Hames2018-09-303-8/+8
| | | | | | | 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-1/+54
| | | | | | | | | | | (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] Fix the unit tests that were broken by r343323.Lang Hames2018-09-281-0/+2
| | | | llvm-svn: 343326
* [ORC] clang-format the ThreadSafeModule code.Lang Hames2018-09-281-3/+3
| | | | | | Evidently I forgot to do this before committing r343055. llvm-svn: 343288
* Re-reapply r343129 with more fixes.Lang Hames2018-09-271-14/+15
| | | | | | Fixes order-of-operand-evaluation bugs in the ThreadSafeModule unit tests. llvm-svn: 343162
* Revert "Re-revert r343129."Lang Hames2018-09-272-0/+95
| | | | | | This reverts commit 4e2557dbc76704beb8c4cf1191cb786e719db5d3. llvm-svn: 343161
* Re-revert r343129.Lang Hames2018-09-262-95/+0
| | | | | | | Apparently the fixes in r343149 did not cover all the issues. Re-reverting while I investigate. llvm-svn: 343151
* Reapply r343129 with fix.Lang Hames2018-09-262-0/+95
| | | | | | | | Explicitly defines ThreadSafeModule's move-assignment operator to move fields in reverse order. This is required to ensure that the context field outlives the module field. llvm-svn: 343149
* Revert r343129 "[ORC] Change the field order of ThreadSafeModule to ensure the "Lang Hames2018-09-262-85/+0
| | | | | | It broke several bots. llvm-svn: 343133
* [ORC] Change the field order of ThreadSafeModule to ensure the Module isLang Hames2018-09-262-0/+85
| | | | | | | | | | | | destroyed before its ThreadSharedContext. Destroying the context first is an error if this ThreadSafeModule is the only owner of its underlying context. Add a unit test for ThreadSafeModule/ThreadSafeContext to catch this and other basic usage issues. llvm-svn: 343129
* [ORC] Add a "lazy call-through" utility based on the same underlying trampolineLang Hames2018-09-264-38/+114
| | | | | | | | | | | | | | | | | | | | 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-261-4/+9
| | | | | | | | | | | | | | | | | 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 ThreadSafeModule and ThreadSafeContext wrappers to support concurrentLang Hames2018-09-261-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 a special 'main' JITDylib that is created on ExecutionSessionLang Hames2018-09-122-2/+12
| | | | | | | | | | | | | | | | | | | | | construction, a new convenience lookup method, and add-to layer methods. ExecutionSession now creates a special 'main' JITDylib upon construction. All subsequently created JITDylibs are added to the main JITDylib's search order by default (controlled by the AddToMainDylibSearchOrder parameter to ExecutionSession::createDylib). The main JITDylib's search order will be used in the future to properly handle cross-JITDylib weak symbols, with the first definition in this search order selected. This commit also adds a new ExecutionSession::lookup convenience method that performs a blocking lookup using the main JITDylib's search order, as this will be a very common operation for clients. Finally, new convenience overloads of IRLayer and ObjectLayer's add methods are introduced that add the given program representations to the main dylib, which is likely to be the common case. llvm-svn: 342086
* [ORC] Make RuntimeDyldObjectLinkingLayer2 take memory managers by unique_ptr.Lang Hames2018-09-061-185/+5
| | | | | | | | | | | | The existing memory manager API can not be shared between objects when linking concurrently (since there is no way to know which concurrent allocations were performed on behalf of which object, and hence which allocations would be safe to finalize when finalizeMemory is called). For now, we can work around this by requiring a new memory manager for each object. This change only affects the concurrent version of the ORC APIs. llvm-svn: 341579
* Remove some unnecessary constructor arguments.Lang Hames2018-09-052-8/+8
| | | | | | | ExecutionSession defaults to creating a new shared pool if none is provided, so explicitly passing one in is unnecessary. llvm-svn: 341494
* [ORC] Tidy up JITSymbolFlags to remove the need for some explicit static_casts.Lang Hames2018-09-022-6/+3
| | | | | | | | Removes the implicit conversion to the underlying type for JITSymbolFlags::FlagNames and replaces it with some bitwise and comparison operators. llvm-svn: 341282
* [ORC] Remove a stray debugging output line left in a unit test.Lang Hames2018-08-311-1/+0
| | | | llvm-svn: 341155
* [ORC] Add utilities to RTDyldObjectLinkingLayer2 to simplify symbol flagLang Hames2018-08-311-0/+123
| | | | | | | | | | | | | | | | | | | | | | | management and materialization responsibility registration. The setOverrideObjectFlagsWithResponsibilityFlags method instructs RTDyldObjectlinkingLayer2 to override the symbol flags produced by RuntimeDyld with the flags provided by the MaterializationResponsibility instance. This can be used to enable symbol visibility (hidden/exported) for COFF object files, which do not currently support the SF_Exported flag. The setAutoClaimResponsibilityForObjectSymbols method instructs RTDyldObjectLinkingLayer2 to claim responsibility for any symbols provided by a given object file that were not already in the MaterializationResponsibility instance. Setting this flag allows higher-level program representations (e.g. LLVM IR) to be added based on only a subset of the symbols they provide, without having to write intervening layers to scan and add the additional symbols. This trades diagnostic quality for convenience however: If all symbols are enumerated up-front then clashes can be detected and reported early. If this option is set, clashes for the additional symbols may not be detected until late, and detection may depend on the flow of control through JIT'd code. llvm-svn: 341154
* [ORC] Replace lookupFlags in JITSymbolResolver with getResponsibilitySet.Lang Hames2018-08-283-83/+88
| | | | | | | | | | | | | | The new method name/behavior more closely models the way it was being used. It also fixes an assertion that can occur when using the new ORC Core APIs, where flags alone don't necessarily provide enough context to decide whether the caller is responsible for materializing a given symbol (which was always the reason this API existed). The default implementation of getResponsibilitySet uses lookupFlags to determine responsibility as before, so existing JITSymbolResolvers should continue to work. llvm-svn: 340874
* [ORC] Add unit tests for the new RTDyldObjectLinkingLayer2 class.Lang Hames2018-08-272-0/+283
| | | | | | | The new unit tests match the old ones, which will remain in tree until the old RTDyldObjectLinkingLayer is removed. llvm-svn: 340786
* [ORC] Remove a workaround for systems lacking 8-byte atomics.Lang Hames2018-08-261-5/+0
| | | | | | | SymbolStringPool ref counts are now size_t, rather than uint64_t, so I do not think this is necessary any more. llvm-svn: 340704
* [ORC] Rename 'finalize' to 'emit' to avoid potential confusion.Lang Hames2018-08-181-18/+18
| | | | | | | | | | | | | | | An emitted symbol has had its contents written and its memory protections applied, but it is not automatically ready to execute. Prior to ORC supporting concurrent compilation, the term "finalized" could be interpreted two different (but effectively equivalent) ways: (1) The finalized symbol's contents have been written and its memory protections applied, and (2) the symbol is ready to run. Now that ORC supports concurrent compilation, sense (1) no longer implies sense (2). We have already introduced a new term, 'ready', to capture sense (2), so rename sense (1) to 'emitted' to avoid any lingering confusion. llvm-svn: 340115
* [ORC] Rename VSO to JITDylib.Lang Hames2018-08-173-101/+103
| | | | | | | | | | | | | VSO was a little close to VDSO (an acronym on Linux for Virtual Dynamic Shared Object) for comfort. It also risks giving the impression that instances of this class could be shared between ExecutionSessions, which they can not. JITDylib seems moderately less confusing, while still hinting at how this class is intended to be used, i.e. as a JIT-compiled stand-in for a dynamic library (code that would have been a dynamic library if you had wanted to compile it ahead of time). llvm-svn: 340084
* [ORC] Add a re-exports fallback definition generator.Lang Hames2018-08-021-0/+22
| | | | | | | | An instance of ReexportsFallbackDefinitionGenerator can be attached to a VSO (via setFallbackDefinitionGenerator) to re-export symbols on demandy from a backing VSO. llvm-svn: 338764
* [ORC] Add SerializationTraits for std::set and std::map.Lang Hames2018-07-301-37/+44
| | | | | | | | | | Also, make SerializationTraits for pairs forward the actual pair template type arguments to the underlying serializer. This allows, for example, std::pair<StringRef, bool> to be passed as an argument to an RPC call expecting a std::pair<std::string, bool>, since there is an underlying serializer from StringRef to std::string that can be used. llvm-svn: 338305
* [ORC] Re-apply r336760 with fixes.Lang Hames2018-07-211-6/+48
| | | | llvm-svn: 337637
* Re-apply r337595 with fix for LLVM_ENABLE_THREADS=Off.Lang Hames2018-07-202-182/+135
| | | | llvm-svn: 337626
* Revert r337595 "[ORC] Add new symbol lookup methods to ExecutionSessionBase ↵Reid Kleckner2018-07-202-135/+182
| | | | | | | | in preparation for" Breaks the build with LLVM_ENABLE_THREADS=OFF. llvm-svn: 337608
* [ORC] Add new symbol lookup methods to ExecutionSessionBase in preparation forLang Hames2018-07-202-182/+135
| | | | | | | | | | | | deprecating SymbolResolver and AsynchronousSymbolQuery. Both lookup overloads take a VSO search order to perform the lookup. The first overload is non-blocking and takes OnResolved and OnReady callbacks. The second is blocking, takes a boolean flag to indicate whether to wait until all symbols are ready, and returns a SymbolMap. Both overloads take a RegisterDependencies function to register symbol dependencies (if any) on the query. llvm-svn: 337595
* [ORC] Simplify VSO::lookupFlags to return the flags map.Lang Hames2018-07-203-32/+15
| | | | | | | | | | | This discards the unresolved symbols set and returns the flags map directly (rather than mutating it via the first argument). The unresolved symbols result made it easy to chain lookupFlags calls, but such chaining should be rare to non-existant (especially now that symbol resolvers are being deprecated) so the simpler method signature is preferable. llvm-svn: 337594
* [ORC] Replace SymbolResolvers in the new ORC layers with search orders on VSOs.Lang Hames2018-07-204-100/+109
| | | | | | | | | | | | | | | A search order is a list of VSOs to be searched linearly to find symbols. Each VSO now has a search order that will be used when fixing up definitions in that VSO. Each VSO's search order defaults to just that VSO itself. This is a first step towards removing symbol resolvers from ORC altogether. In practice symbol resolvers tended to be used to implement a search order anyway, sometimes with additional programatic generation of symbols. Now that VSOs support programmatic generation of definitions via fallback generators, search orders provide a cleaner way to achieve the desired effect (while removing a lot of boilerplate). llvm-svn: 337593
* Revert r336760: "[ORC] Add unit tests for the reexports utility that were..."Lang Hames2018-07-111-42/+0
| | | | | | | This patch broke a few buildbots. I will investigate and re-apply when I have a fix. llvm-svn: 336767
* [ORC] Remove a shadowing definition.Lang Hames2018-07-111-2/+0
| | | | | | There is already a VSO member V in the CoreAPIsStandardTest test fixture. llvm-svn: 336761
* [ORC] Add unit tests for the reexports utility that were left out of r336741,Lang Hames2018-07-111-0/+42
| | | | | | and fix a bug that these exposed. llvm-svn: 336760
* [ORC] Drop constexpr in unit test to appease a bot.Lang Hames2018-07-111-4/+4
| | | | llvm-svn: 336758
* [ORC] Use a gtest fixture to remove a bunch of boilerplate in CoreAPIsTest.cpp.Lang Hames2018-07-111-299/+144
| | | | llvm-svn: 336757
* [ORC] Generalize alias materialization to support re-exports (i.e. aliasing ofLang Hames2018-07-101-1/+26
| | | | | | | | | symbols in another VSO). Also fixes a bug where chained aliases within a single VSO would deadlock on materialization. llvm-svn: 336741
* [ORC] Rename MaterializationResponsibility::delegate to replace and add a newLang Hames2018-07-091-2/+36
| | | | | | | | | | | | | delegate method (and unit test). The name 'replace' better captures what the old delegate method did: it returned materialization responsibility for a set of symbols to the VSO. The new delegate method delegates responsibility for a set of symbols to a new MaterializationResponsibility instance. This can be used to split responsibility between multiple threads, or multiple materialization methods. llvm-svn: 336603
* [ORC] Add a symbolAliases function to the Core APIs.Lang Hames2018-06-261-0/+29
| | | | | | symbolAliases can be used to define symbol aliases within a VSO. llvm-svn: 335565
* [ORC] Only notify queries that they are resolved/ready when the query stateLang Hames2018-06-171-0/+54
| | | | | | | | changes. This guards against redundant notifications. llvm-svn: 334916
* [ORC] Erase empty dependence sets when adding new symbol dependencies.Lang Hames2018-06-171-0/+38
| | | | llvm-svn: 334910
* [ORC] Strip weak flags from a symbol once it is selected for materialization.Lang Hames2018-06-141-0/+47
| | | | | | | | | Once a symbol has been selected for materialization it can no longer be overridden. Stripping the weak flag guarantees this (override attempts will then be treated as duplicate definitions and result in a DuplicateDefinition error). llvm-svn: 334771
* [ORC] Filter out self-dependencies in VSO::addDependencies.Lang Hames2018-06-141-0/+7
| | | | llvm-svn: 334724
* [ORC] Add a fallback definition generator for VSOs.Lang Hames2018-06-121-0/+27
| | | | | | | | | | | | If a VSO has a fallback definition generator attached it will be called during lookup (and lookupFlags) for any unresolved symbols. The definition generator can add new definitions to the VSO for any unresolved symbol. This allows VSOs to generate new definitions on demand. The immediate use case for this code is supporting VSOs that can import definitions found via dlsym on demand. llvm-svn: 334538
* [ORC] Use JITEvaluatedSymbol for IndirectStubsManager findStub and findPointer.Lang Hames2018-06-031-2/+2
| | | | | | | | Existing implementations of these methods do not require lazy materialization, and switching to JITEvaluatedSymbol allows us to remove error checking on the client side. llvm-svn: 333835
* [ORC] Add a getRequestedSymbols method to MaterializationResponsibility.Lang Hames2018-05-311-0/+56
| | | | | | | | | | | This method returns the set of symbols in the target VSO that have queries waiting on them. This can be used to make decisions about which symbols to delegate to another MaterializationUnit (typically this will involve delegating all symbols that have *not* been requested to another MaterializationUnit so that materialization of those symbols can be deferred until they are requested). llvm-svn: 333684
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-302-3/+5
| | | | | | | | | Previously JITCompileCallbackManager only supported single threaded code. This patch embeds a VSO (see include/llvm/ExecutionEngine/Orc/Core.h) in the callback manager. The VSO ensures that the compile callback is only executed once and that the resulting address cached for use by subsequent re-entries. llvm-svn: 333490
* [ORC] Add findSymbolIn() wrapper to C bindings, take #2.Andres Freund2018-05-241-6/+20
| | | | | | | | | | | | | | | | Re-appply r333147, reverted in r333152 due to a pre-existing bug. As D47308 has been merged in r333206, the OSX issue should now be resolved. In many cases JIT users will know in which module a symbol resides. Avoiding to search other modules can be more efficient. It also allows to handle duplicate symbol names between modules. Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D44889 llvm-svn: 333215
OpenPOWER on IntegriCloud