summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [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
OpenPOWER on IntegriCloud