summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine
Commit message (Collapse)AuthorAgeFilesLines
* [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-253-60/+182
| | | | | | | | | | | | | | | | | 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
* Remove 'orc' namespace from MSVCErrorWorkarounds.h, fix some typos that wereLang Hames2018-09-252-2/+2
| | | | | | | | | breaking windows builds. The 'orc' namespace was accidentally left in when the workarounds were moved out of orc in r343011. llvm-svn: 343025
* Fix a missing includes and a use of the MSVC promise/future workaround thatLang Hames2018-09-252-2/+10
| | | | | | were left out of r343011/r343012. llvm-svn: 343022
* [ORC] Reapply r342939 with a fix for MSVC's promise/future restrictions.Lang Hames2018-09-257-89/+151
| | | | llvm-svn: 343012
* Revert "[ORC] Switch to asynchronous resolution in JITSymbolResolver."Lang Hames2018-09-257-145/+89
| | | | | | | | | 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-257-89/+145
| | | | | | | | | | | | | | | | | | | 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
* [ORC] Add a special 'main' JITDylib that is created on ExecutionSessionLang Hames2018-09-121-1/+14
| | | | | | | | | | | | | | | | | | | | | 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
* [MIPS] ORC JIT supportPetar Jovanovic2018-09-113-2/+491
| | | | | | | | | | | | This patch adds support for ORC JIT for mips/mips64 architecture. In common code $static is changed to __ORCstatic because on MIPS architecture "$" is a reserved character. Patch by Luka Ercegovcevic Differential Revision: https://reviews.llvm.org/D49665 llvm-svn: 341934
* [ORC] Render unresolved symbol addresses as "<not resolved>" in JITDylib::dump.Lang Hames2018-09-101-2/+5
| | | | | | This is easier to spot among the real addresses than "0x0000000000000000". llvm-svn: 341873
* [ORC] Simplify LLJIT::Create by removing the ExecutionSession parameter.Lang Hames2018-09-101-6/+6
| | | | | | | The Create method can just construct the ExecutionSession, rather than having the client pass it in. llvm-svn: 341872
* [ORC] Make RuntimeDyldObjectLinkingLayer2 take memory managers by unique_ptr.Lang Hames2018-09-061-1/+1
| | | | | | | | | | | | 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
* [ORC] Remove the mapSectionAddress method from RuntimeDyldObjectLinkingLayer2.Lang Hames2018-09-061-19/+0
| | | | | | | | Section address mappings can be applied using the RuntimeDyld instance passed to the RuntimeDyld::MemoryManager::notifyObjectLoaded method. Proving an alternate route via RuntimeDyldObjectLinkingLayer2 is redundant. llvm-svn: 341578
* clang-format r341282.Lang Hames2018-09-021-1/+2
| | | | llvm-svn: 341283
* [ORC] Tidy up JITSymbolFlags to remove the need for some explicit static_casts.Lang Hames2018-09-021-4/+2
| | | | | | | | Removes the implicit conversion to the underlying type for JITSymbolFlags::FlagNames and replaces it with some bitwise and comparison operators. llvm-svn: 341282
* [ORC] Add utilities to RTDyldObjectLinkingLayer2 to simplify symbol flagLang Hames2018-08-311-4/+32
| | | | | | | | | | | | | | | | | | | | | | | 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-287-74/+69
| | | | | | | | | | | | | | 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 an addObjectFile method to LLJIT.Lang Hames2018-08-281-0/+7
| | | | | | | | | | The addObjectFile method adds the given object file to the JIT session, making its code available for execution. Support for the -extra-object flag is added to lli when operating in -jit-kind=orc-lazy mode to support testing of this feature. llvm-svn: 340870
* [ORC] Do not include non-global symbols in getObjectSymbolFlags.Lang Hames2018-08-261-11/+16
| | | | | | | | | | | Private symbols are not visible outside the object file, and so not defined by the object file from ORC's perspective. No test case yet. Ideally this would be a unit test parsing a checked-in binary, but I am not aware of any way to reference the LLVM source root from a unit test. llvm-svn: 340703
* [RuntimeDyld] Fix a bug in RuntimeDyld::loadObjectImpl that was over-allocatingLang Hames2018-08-181-1/+1
| | | | | | | | | | space for common symbols. Patch by Dmitry Sidorov. Thanks Dmitry! Differential revision: https://reviews.llvm.org/D50240 llvm-svn: 340125
* [ORC] Rename 'finalize' to 'emit' to avoid potential confusion.Lang Hames2018-08-183-57/+57
| | | | | | | | | | | | | | | 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-177-193/+204
| | | | | | | | | | | | | 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
* [MCJIT] Fix a case of Error::success() being passed to report_fatal_error.Lang Hames2018-08-151-1/+2
| | | | | | | | | | MCJIT::getSymbolAddress was handling a non-fatal error condition of JITSymbol as fatal. JITSymbol::operator bool returns false if no address is available but no error is set. This can occur e.g. if the symbol name was not found. Patch by Jascha Wetzel. Thanks Jascha! llvm-svn: 339809
* [ORC] Remove an incorrect use of 'cantFail'.Lang Hames2018-08-051-2/+4
| | | | | | | | This code was moved out from BasicObjectLayerMaterializationUnit, which required the supplied object to be well formed. The getObjectSymbolFlags function does not require a well-formed object, so we have to propagate the error here. llvm-svn: 338975
* [ORC] Change JITSymbolFlags debug output, add a function for getting a symbolLang Hames2018-08-052-30/+39
| | | | | | flags map from a buffer representing an object file. llvm-svn: 338974
* [ORC] Add a re-exports fallback definition generator.Lang Hames2018-08-021-0/+24
| | | | | | | | 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 a 'Callable' flag to JITSymbolFlags.Lang Hames2018-08-015-32/+69
| | | | | | | | | | | | | The callable flag can be used to indicate that a symbol is callable. If present, the symbol is callable. If absent, the symbol may or may not be callable (the client must determine this by context, for example by examining the program representation that will provide the symbol definition). This flag will be used in the near future to enable creation of lazy compilation stubs based on SymbolFlagsMap instances only (without having to provide additional information to determine which symbols need stubs). llvm-svn: 338649
* Remove trailing spaceFangrui Song2018-07-307-82/+82
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338293
* Move JIT listener C binding fallbackks to ExecutionEngineBindings.cpp.Andres Freund2018-07-251-0/+24
| | | | | | | | | | | | | | | | | | | | | Initially, in https://reviews.llvm.org/D44890, I had these defined as empty functions inside the header when the respective event listener was not built in. As done in that commit, that wasn't correct, because it was a ODR violation. Krasimir hot-fixed that in r333265, but that wasn't quite right either, because it'd lead to the symbol not being available. Instead just move the fallbacksto ExecutionEngineBindings.cpp. Could define them as static inlines in the header too, but I don't think it matters. Reviewers: whitequark Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D49654 llvm-svn: 337930
* Add PerfJITEventListener for perf profiling support.Andres Freund2018-07-245-1/+529
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new JIT event listener supports generating profiling data for the linux 'perf' profiling tool, allowing it to generate function and instruction level profiles. Currently this functionality is not enabled by default, but must be enabled with LLVM_USE_PERF=yes. Given that the listener has no dependencies, it might be sensible to enable by default once the initial issues have been shaken out. I followed existing precedent in registering the listener by default in lli. Should there be a decision to enable this by default on linux, that should probably be changed. Please note that until https://reviews.llvm.org/D47343 is resolved, using this functionality with mcjit rather than orcjit will not reliably work. Disregarding the previous comment, here's an example: $ cat /tmp/expensive_loop.c bool stupid_isprime(uint64_t num) { if (num == 2) return true; if (num < 1 || num % 2 == 0) return false; for(uint64_t i = 3; i < num / 2; i+= 2) { if (num % i == 0) return false; } return true; } int main(int argc, char **argv) { int numprimes = 0; for (uint64_t num = argc; num < 100000; num++) { if (stupid_isprime(num)) numprimes++; } return numprimes; } $ clang -ggdb -S -c -emit-llvm /tmp/expensive_loop.c -o /tmp/expensive_loop.ll $ perf record -o perf.data -g -k 1 ./bin/lli -jit-kind=mcjit /tmp/expensive_loop.ll 1 $ perf inject --jit -i perf.data -o perf.jit.data $ perf report -i perf.jit.data - 92.59% lli jitted-5881-2.so [.] stupid_isprime stupid_isprime main llvm::MCJIT::runFunction llvm::ExecutionEngine::runFunctionAsMain main __libc_start_main 0x4bf6258d4c544155 + 0.85% lli ld-2.27.so [.] do_lookup_x And line-level annotations also work: │ for(uint64_t i = 3; i < num / 2; i+= 2) { │1 30: movq $0x3,-0x18(%rbp) 0.03 │1 38: mov -0x18(%rbp),%rax 0.03 │ mov -0x10(%rbp),%rcx │ shr $0x1,%rcx 3.63 │ ┌──cmp %rcx,%rax │ ├──jae 6f │ │ if (num % i == 0) 0.03 │ │ mov -0x10(%rbp),%rax │ │ xor %edx,%edx 89.00 │ │ divq -0x18(%rbp) │ │ cmp $0x0,%rdx 0.22 │ │↓ jne 5f │ │ return false; │ │ movb $0x0,-0x1(%rbp) │ │↓ jmp 73 │ │ } 3.22 │1 5f:│↓ jmp 61 │ │ for(uint64_t i = 3; i < num / 2; i+= 2) { Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D44892 llvm-svn: 337789
* [ORC] Re-apply r336760 with fixes.Lang Hames2018-07-213-4/+38
| | | | llvm-svn: 337637
* Re-apply r337595 with fix for LLVM_ENABLE_THREADS=Off.Lang Hames2018-07-205-281/+518
| | | | llvm-svn: 337626
* Revert r337595 "[ORC] Add new symbol lookup methods to ExecutionSessionBase ↵Reid Kleckner2018-07-205-518/+281
| | | | | | | | 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-205-281/+518
| | | | | | | | | | | | 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-206-31/+27
| | | | | | | | | | | 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-205-97/+148
| | | | | | | | | | | | | | | 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
* Fix few typos in comments (write access test commit)Stefan Granitz2018-07-121-2/+2
| | | | llvm-svn: 336887
OpenPOWER on IntegriCloud