summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Add support for emulated TLS to ORCv2.Lang Hames2020-01-295-14/+17
| | | | | | | | | | | | | | | | | | | | | | | This commit adds a ManglingOptions struct to IRMaterializationUnit, and replaces IRCompileLayer::CompileFunction with a new IRCompileLayer::IRCompiler class. The ManglingOptions struct defines the emulated-TLS state (via a bool member, EmulatedTLS, which is true if emulated-TLS is enabled and false otherwise). The IRCompileLayer::IRCompiler class wraps an IRCompiler (the same way that the CompileFunction typedef used to), but adds a method to return the IRCompileLayer::ManglingOptions that the compiler will use. These changes allow us to correctly determine the symbols that will be produced when a thread local global variable defined at the IR level is compiled with or without emulated TLS. This is required for ORCv2, where MaterializationUnits must declare their interface up-front. Most ORCv2 clients should not require any changes. Clients writing custom IR compilers will need to wrap their compiler in an IRCompileLayer::IRCompiler, rather than an IRCompileLayer::CompileFunction, however this should be a straightforward change (see modifications to CompileUtils.* in this patch for an example). (cherry picked from commit ce2207abaf9a925b35f15ef92aaff6b301ba6d22)
* [unittests] Fix "comparison of integers of different signs" warningsMiloš Stojanović2020-01-141-5/+4
| | | | | | | | A warning is sent because `std::distance()` returns a signed type so `CmpHelperEQ()` gets instantiated into a function that compares differently signed arguments. Differential Revision: https://reviews.llvm.org/D72632
* [ORC][JITLink] Add support for weak references, and improve handling of staticLang Hames2019-11-283-94/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | libraries. This patch substantially updates ORCv2's lookup API in order to support weak references, and to better support static archives. Key changes: -- Each symbol being looked for is now associated with a SymbolLookupFlags value. If the associated value is SymbolLookupFlags::RequiredSymbol then the symbol must be defined in one of the JITDylibs being searched (or be able to be generated in one of these JITDylibs via an attached definition generator) or the lookup will fail with an error. If the associated value is SymbolLookupFlags::WeaklyReferencedSymbol then the symbol is permitted to be undefined, in which case it will simply not appear in the resulting SymbolMap if the rest of the lookup succeeds. Since lookup now requires these flags for each symbol, the lookup method now takes an instance of a new SymbolLookupSet type rather than a SymbolNameSet. SymbolLookupSet is a vector-backed set of (name, flags) pairs. Clients are responsible for ensuring that the set property (i.e. unique elements) holds, though this is usually simple and SymbolLookupSet provides convenience methods to support this. -- Lookups now have an associated LookupKind value, which is either LookupKind::Static or LookupKind::DLSym. Definition generators can inspect the lookup kind when determining whether or not to generate new definitions. The StaticLibraryDefinitionGenerator is updated to only pull in new objects from the archive if the lookup kind is Static. This allows lookup to be re-used to emulate dlsym for JIT'd symbols without pulling in new objects from archives (which would not happen in a normal dlsym call). -- JITLink is updated to allow externals to be assigned weak linkage, and weak externals now use the SymbolLookupFlags::WeaklyReferencedSymbol value for lookups. Unresolved weak references will be assigned the default value of zero. Since this patch was modifying the lookup API anyway, it alo replaces all of the "MatchNonExported" boolean arguments with a "JITDylibLookupFlags" enum for readability. If a JITDylib's associated value is JITDylibLookupFlags::MatchExportedSymbolsOnly then the lookup will only match against exported (non-hidden) symbols in that JITDylib. If a JITDylib's associated value is JITDylibLookupFlags::MatchAllSymbols then the lookup will match against any symbol defined in the JITDylib.
* [JITLink] Move block ownership from LinkGraph to Section.Lang Hames2019-10-301-3/+57
| | | | This enables easy iteration over blocks in a specific section.
* [JITLink] Remove relocation unit tests.Lang Hames2019-10-304-698/+0
| | | | | These tests were written before llvm-jitlink supported regression testing of relocation support. They are now redundant.
* [JITLink] Add missing include, explicitly qualify STLExtras functions.Lang Hames2019-10-301-6/+7
| | | | | This should fix the failures on some bots due to commit b9d8e23b806ca605c368f924cca75bdd090834c6.
* [JITLink] Add a utility for splitting blocks at a given index.Lang Hames2019-10-302-0/+121
| | | | | | | | LinkGraph::splitBlock will split a block at a given index, returning a new block covering the range [ 0, index ) and modifying the original block to cover the range [ index, original-block-size ). Block addresses, content, edges and symbols will be updated as necessary. This utility will be used in upcoming improvements to JITLink's eh-frame support.
* [Orc][test] Fix -DBUILD_SHARED_LIBS=on buildFangrui Song2019-10-291-0/+1
|
* Break out OrcError and RPCChris Bieneman2019-10-292-2/+2
| | | | | | | | | | | | | | | | | | | Summary: When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more. This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory. With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport. Reviewers: lhames Reviewed By: lhames Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68732
* [Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin2019-10-231-1/+3
| | | | | | | | | | MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
* [JITLink] Switch from an atom-based model to a "blocks and symbols" model.Lang Hames2019-10-043-103/+108
| | | | | | | | | | | | | | | | | | | | | | | | In the Atom model the symbols, content and relocations of a relocatable object file are represented as a graph of atoms, where each Atom represents a contiguous block of content with a single name (or no name at all if the content is anonymous), and where edges between Atoms represent relocations. If more than one symbol is associated with a contiguous block of content then the content is broken into multiple atoms and layout constraints (represented by edges) are introduced to ensure that the content remains effectively contiguous. These layout constraints must be kept in mind when examining the content associated with a symbol (it may be spread over multiple atoms) or when applying certain relocation types (e.g. MachO subtractors). This patch replaces the Atom model in JITLink with a blocks-and-symbols model. The blocks-and-symbols model represents relocatable object files as bipartite graphs, with one set of nodes representing contiguous content (Blocks) and another representing named or anonymous locations (Symbols) within a Block. Relocations are represented as edges from Blocks to Symbols. This scheme removes layout constraints (simplifying handling of MachO alt-entry symbols, and hopefully ELF sections at some point in the future) and simplifies some relocation logic. llvm-svn: 373689
* [Orc] Address the remaining move-capture FIXMEsBenjamin Kramer2019-09-131-2/+1
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* [ORC][RPC] Join server thread before checking condition in unit test.Lang Hames2019-09-061-2/+2
| | | | | | Otherwise we have a race on the sent-messages count. llvm-svn: 371263
* [ORC] Add a missing #include atomic.Lang Hames2019-09-061-0/+1
| | | | | | Hopefully this will fix the bot build failures from r371245. llvm-svn: 371255
* [ORC] Make sure RPC channel-send is called in blocking calls and responses.Lang Hames2019-09-062-1/+44
| | | | | | | | | ORC-RPC batches calls by default, and the channel's send method must be called to transfer any buffered calls to the remote. The call to send was missing on responses and blocking calls in the SingleThreadedRPCEndpoint. This patch adds the necessary calls and modifies the RPC unit test to check for them. llvm-svn: 371245
* Skip MCJIT unit tests if LLVM is not configured for native compilationDavid Blaikie2019-09-031-1/+7
| | | | | | | | Patch by Sergej Jaskiewicz! Differential Revision: D67089 llvm-svn: 370812
* [ORC] Make sure that queries on emitted-but-not-ready symbols fail correctly.Lang Hames2019-08-261-0/+54
| | | | | | | | | | | | | | | | | In r369808 the failure scheme for ORC symbols was changed to make MaterializationResponsibility objects responsible for failing the symbols they represented. This simplifies error logic in the case where symbols are still covered by a MaterializationResponsibility, but left a gap in error handling: Symbols that have been emitted but are not yet ready (due to a dependence on some unemitted symbol) are not covered by a MaterializationResponsibility object. Under the scheme introduced in r369808 such symbols would be moved to the error state, but queries on those symbols were never notified. This led to deadlocks when such symbols were failed. This commit updates error logic to immediately fail queries on any symbol that has already been emitted if one of its dependencies fails. llvm-svn: 369976
* [ORC] Fix an overly aggressive assert.Lang Hames2019-08-261-0/+29
| | | | | | | | Symbols that have not been queried will not have MaterializingInfo entries, so remove the assert that all failed symbols should have these entries. Also updates the loop to only remove entries that were found earlier. llvm-svn: 369975
* [ORC] Remove query dependencies when symbols are resolved.Lang Hames2019-08-231-1/+25
| | | | | | | | | | If the dependencies are not removed then a late failure (one symbol covered by the query failing after others have already been resolved) can result in an attempt to detach the query from already finalized symbol, resulting in an assert/crash. This patch fixes the issue by removing query dependencies in JITDylib::resolve for symbols that meet the required state. llvm-svn: 369809
* [ORC] Fix a FIXME: Propagate errors to dependencies.Lang Hames2019-08-232-52/+255
| | | | | | | | | | | | | When symbols are failed (via MaterializationResponsibility::failMaterialization) any symbols depending on them will now be moved to an error state. Attempting to resolve or emit a symbol in the error state (via the notifyResolved or notifyEmitted methods on MaterializationResponsibility) will result in an error. If notifyResolved or notifyEmitted return an error due to failure of a dependence then the caller should log or discard the error and call failMaterialization to propagate the failure to any queries waiting on the symbols being resolved/emitted (plus their dependencies). llvm-svn: 369808
* [cmake] Link in LLVMPasses due to dependency by LLVMOrcJIT; NFCHubert Tong2019-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: rL367756 (f5c40cb) increases the dependency of LLVMOrcJIT on LLVMPasses. In particular, symbols defined in LLVMPasses that are referenced by the destructor of `PassBuilder` are now referenced by LLVMOrcJIT through `Speculation.cpp.o`. We believe that referencing symbols defined in LLVMPasses in the destructor of `PassBuilder` is valid, and that adding to the set of such symbols is legitimate. To support such cases, this patch adds LLVMPasses to the set of libraries being linked when linking in LLVMOrcJIT causes such symbols from LLVMPasses to be referenced. Reviewers: Whitney, anhtuyen, pree-jackie Reviewed By: pree-jackie Subscribers: mgorny, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66441 llvm-svn: 369310
* [ORC] Re-introduce self-dependence accidentally dropped from a unit test.Lang Hames2019-08-161-0/+1
| | | | llvm-svn: 369171
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1510-57/+57
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [ORC] Refactor definition-generation, add a generator for static libraries.Lang Hames2019-08-131-8/+28
| | | | | | | | | | | | | | | | | This patch replaces the JITDylib::DefinitionGenerator typedef with a class of the same name, and adds support for attaching a sequence of DefinitionGeneration objects to a JITDylib. This patch also adds a new definition generator, StaticLibraryDefinitionGenerator, that can be used to add symbols fom a static library to a JITDylib. An object from the static library will be added (via a supplied ObjectLayer reference) whenever a symbol from that object is referenced. To enable testing, lli is updated to add support for the --extra-archive option when running in -jit-kind=orc-lazy mode. llvm-svn: 368707
* [ORC] Remove some old debugging output from a unit test.Lang Hames2019-08-031-2/+0
| | | | llvm-svn: 367742
* [ORC] Change the locking scheme for ThreadSafeModule.Lang Hames2019-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon as an associated Module was emitted (to be compiled and linked), and were not unlocked until the emit call returned. This could lead to deadlocks if interdependent modules that shared contexts were compiled on different threads: when, during emission of the first module, the dependence was discovered the second module (which would provide the required symbol) could not be emitted as the thread emitting the first module still held the lock. This patch eliminates this possibility by moving to a finer-grained locking scheme. Each client holds the module lock only while they are actively operating on it. To make this finer grained locking simpler/safer to implement this patch removes the explicit lock method, 'getContextLock', from ThreadSafeModule and replaces it with a new method, 'withModuleDo', that implicitly locks the context, calls a user-supplied function object to operate on the Module, then implicitly unlocks the context before returning the result. ThreadSafeModule TSM = getModule(...); size_t NumFunctions = TSM.withModuleDo( [](Module &M) { // <- context locked before entry to lambda. return M.size(); }); Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the new method. This method is used to introduce Module locking into each of the existing layers. llvm-svn: 367686
* [ORC] Add deprecation warnings to ORCv1 layers and utilities.Lang Hames2019-07-175-64/+73
| | | | | | | | | | | | | | | | | Summary: ORCv1 is deprecated. The current aim is to remove it before the LLVM 10.0 release. This patch adds deprecation attributes to the ORCv1 layers and utilities to warn clients of the change. Reviewers: dblaikie, sgraenitz, AlexDenisov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64609 llvm-svn: 366344
* [ORC] Rename MaterializationResponsibility resolve and emit methods toLang Hames2019-06-132-36/+36
| | | | | | | | | | | | | notifyResolved/notifyEmitted. The 'notify' prefix better describes what these methods do: they update the JIT symbol states and notify any pending queries that the 'resolved' and 'emitted' states have been reached (rather than actually performing the resolution or emission themselves). Since new states are going to be introduced in the near future (to track symbol registration/initialization) it's worth changing the convention pre-emptively to avoid further confusion. llvm-svn: 363322
* [ORC] Update symbol lookup to use a single callback with a required symbol stateLang Hames2019-06-073-151/+102
| | | | | | | | | | | | | | | | | | | | | | | rather than two callbacks. The asynchronous lookup API (which the synchronous lookup API wraps for convenience) used to take two callbacks: OnResolved (called once all requested symbols had an address assigned) and OnReady to be called once all requested symbols were safe to access). This patch updates the asynchronous lookup API to take a single 'OnComplete' callback and a required state (SymbolState) to determine when the callback should be made. This simplifies the common use case (where the client is interested in a specific state) and will generalize neatly as new states are introduced to track runtime initialization of symbols. Clients who were making use of both callbacks in a single query will now need to issue two queries (one for SymbolState::Resolved and another for SymbolState::Ready). Synchronous lookup API clients who were explicitly passing the WaitOnReady argument will now need neeed to pass a SymbolState instead (for 'WaitOnReady == true' use SymbolState::Ready, for 'WaitOnReady == false' use SymbolState::Resolved). Synchronous lookup API clients who were using default arugment values should see no change. llvm-svn: 362832
* [ORC] Fix an ambiguous call in a unit test.Lang Hames2019-04-301-1/+2
| | | | llvm-svn: 359529
* [ORC] Allow JITDylib definition generators to return Errors.Lang Hames2019-04-302-5/+25
| | | | | | | | | | | | | | | | | | | | Background: A definition generator can be attached to a JITDylib to generate new definitions in response to queries. For example: a generator that forwards calls to dlsym can map symbols from a dynamic library into the JIT process on demand. If definition generation fails then the generator should be able to return an error. This allows the JIT API to distinguish between the case where a generator does not provide a definition, and the case where it was not able to determine whether it provided a definition due to an error. The immediate motivation for this is cross-process symbol lookups: If the remote-lookup generator is attached to a JITDylib early in the search list, and if a generator failure is misinterpreted as "no definition in this JITDylib" then lookup may continue and bind to a different definition in a later JITDylib, which is a bug. llvm-svn: 359521
* [ORC] Remove symbols from dependency lists when failing materialization.Lang Hames2019-04-252-1/+39
| | | | | | | | | When failing materialization of a symbol X, remove X from the dependants list of any of X's dependencies. This ensures that when X's dependencies are emitted (or fail themselves) they do not try to access the no-longer-existing MaterializationInfo for X. llvm-svn: 359252
* [JITLink] Remove a lot of reduntant 'JITLink_' prefixes. NFC.Lang Hames2019-04-222-3/+3
| | | | llvm-svn: 358869
* [JITLink] Add dependency on MCParser to unit test after rL358818Fangrui Song2019-04-211-0/+1
| | | | | | This is required by -DBUILD_SHARED_LIBS=on builds for createMCAsmParser. llvm-svn: 358842
* [JITLink] Add dependencies on MCDissassembler and Target to unit test.Lang Hames2019-04-211-0/+2
| | | | llvm-svn: 358836
* [JITLink] Add check to JITLink unit test to bail out for unsupported targets.Lang Hames2019-04-203-19/+52
| | | | | | | This should prevent spurious JITLink unit test failures for builds that do not support the target(s) required by the tests. llvm-svn: 358825
* Initial implementation of JITLink - A replacement for RuntimeDyld.Lang Hames2019-04-205-0/+668
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-012-3/+3
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1927-108/+81
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove TypeBuilder.h, and fix the few locations using it.James Y Knight2019-01-139-81/+112
| | | | | | | | | | | | | | This shortcut mechanism for creating types was added 10 years ago, but has seen almost no uptake since then, neither internally nor in external projects. The very small number of characters saved by using it does not seem worth the mental overhead of an additional type-creation API, so, delete it. Differential Revision: https://reviews.llvm.org/D56573 llvm-svn: 351020
* [Support] Make error banner optional in logAllUnhandledErrorsJonas Devlieghere2018-11-111-12/+9
| | | | | | | | In a lot of places an empty string was passed as the ErrorBanner to logAllUnhandledErrors. This patch makes that argument optional to simplify the call sites. llvm-svn: 346604
* [ORC] Re-apply r345077 with fixes to remove ambiguity in lookup calls.Lang Hames2018-10-232-34/+48
| | | | llvm-svn: 345098
* Revert r345077 "[ORC] Change how non-exported symbols are matched during ↵Reid Kleckner2018-10-232-37/+32
| | | | | | | | | | | | | | | 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-232-32/+37
| | | | | | | | | | | | | | | | | 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] Make the VModuleKey optional, propagate it via MaterializationUnit andLang Hames2018-10-162-8/+7
| | | | | | | | | | | | | | | | | | | | | | 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-156-437/+437
| | | | | | | | | | | | | 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] Simplify naming for JITDylib definition generators.Lang Hames2018-10-151-11/+8
| | | | | | | | | 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-131-26/+34
| | | | | | | | | | | | 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] Consume unhandled errors in unit test.Lang Hames2018-10-071-0/+2
| | | | | | This should fix the failures on the debug buildbots. llvm-svn: 343929
* [ORC] Add a 'remove' method to JITDylib to remove symbols.Lang Hames2018-10-061-0/+86
| | | | | | | | 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
OpenPOWER on IntegriCloud