summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
...
* [ORC] Fix a data race in the lookup function.Lang Hames2018-03-141-10/+24
| | | | | | | | | | | The Error locals need to be protected by a mutex. (This could be fixed by having the promises / futures contain Expected and Error values, but MSVC's future implementation does not support this yet). Hopefully this will fix some of the errors seen on the builders due to r327474. llvm-svn: 327477
* [ORC] Silence a compiler error.Lang Hames2018-03-141-1/+1
| | | | | | | This should fix the builder error at http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/19006 llvm-svn: 327475
* [ORC] Add a 'lookup' convenience function for finding symbols in a list of VSOs.Lang Hames2018-03-141-0/+118
| | | | | | | | | | | | | | The lookup function takes a list of VSOs, a set of symbol names (or just one symbol name) and a materialization function object. It returns an Expected<SymbolMap> (if given a set of names) or an Expected<JITEvaluatedSymbol> (if given just one name). The lookup method constructs an AsynchronousSymbolQuery for the given names, applies that query to each VSO in the list in turn, and then blocks waiting for the query to complete. If threading is enabled then the materialization function object can be used to execute the materialization on different threads. If threading is disabled the MaterializeOnCurrentThread utility must be used. llvm-svn: 327474
* [ORC] Switch to shared_ptr ownership for SymbolSources in VSOs.Lang Hames2018-02-211-48/+59
| | | | | | | This makes it easy to free a SymbolSource (and any related resources) when the last reference in a VSO is dropped. llvm-svn: 325727
* [ORC] Switch RTDyldObjectLinkingLayer to take a unique_ptr<MemoryBuffer> ratherLang Hames2018-02-212-23/+15
| | | | | | | | | | than a shared ObjectFile/MemoryBuffer pair. There's no need to pre-parse the buffer into an ObjectFile before passing it down to the linking layer, and moving the parsing into the linking layer allows us remove the parsing code at each call site. llvm-svn: 325725
* [ORC] Consolidate RTDyldObjectLinkingLayer GetMemMgr and GetResolver into aLang Hames2018-02-142-7/+8
| | | | | | | | | unified GetResources callback. Having a single 'GetResources' callback will simplify adding new resources in the future. llvm-svn: 325180
* [ORC] Switch to shared_ptr ownership for AsynchronousSymbolQueries.Lang Hames2018-02-145-35/+39
| | | | | | | Queries need to stay alive until each owner has set the values they are responsible for. llvm-svn: 325179
* [ORC] Remove Layer handles from the layer concept.Lang Hames2018-02-092-105/+56
| | | | | | | | | Handles were returned by addModule and used as keys for removeModule, findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys, which simplify resource management by providing a consistent handle across all layers. llvm-svn: 324700
* [ORC] Use explicit constructor calls to fix a builder error atLang Hames2018-02-061-3/+3
| | | | | | http://lab.llvm.org:8011/builders/lld-x86_64-darwin13/builds/17627 llvm-svn: 324411
* [ORC] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames2018-02-064-86/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular this patch switches RTDyldObjectLinkingLayer to use orc::SymbolResolver and threads the requried changse (ExecutionSession references and VModuleKeys) through the existing layer APIs. The purpose of the new resolver interface is to improve query performance and better support parallelism, both in JIT'd code and within the compiler itself. The most visibile change is switch of the <Layer>::addModule signatures from: Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod, std::shared_ptr<JITSymbolResolver> Resolver) to: Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod); Typical usage of addModule will now look like: auto K = ES.allocateVModuleKey(); Resolvers[K] = createSymbolResolver(...); Layer.addModule(K, std::move(Mod)); See the BuildingAJIT tutorial code for example usage. llvm-svn: 324405
* [ORC] Rename NullResolver to NullLegacyResolver.Lang Hames2018-02-031-2/+3
| | | | | | | | | This resolver conforms to the LegacyJITSymbolResolver interface, and will be replaced with a null-returning resolver conforming to the newer orc::SymbolResolver interface in the near future. This patch renames the class to avoid a clash. llvm-svn: 324175
* [ORC] Refactor the various lookupFlags methods to return the flags map via theLang Hames2018-01-252-5/+6
| | | | | | | | | | | | first argument. This makes lookupFlags more consistent with lookup (which takes the query as the first argument) and composes better in practice, since lookups are usually linearly chained: Each lookupFlags can populate the result map based on the symbols not found in the previous lookup. (If the maps were returned rather than passed by reference there would have to be a merge step at the end). llvm-svn: 323398
* [ORC] Add orc::SymbolResolver, a Orc/Legacy API interop header, and anLang Hames2018-01-223-1/+80
| | | | | | | | | | | | | | | orc::SymbolResolver to JITSymbolResolver adapter. The new orc::SymbolResolver interface uses asynchronous queries for better performance. (Asynchronous queries with bulk lookup minimize RPC/IPC overhead, support parallel incoming queries, and expose more available work for distribution). Existing ORC layers will soon be updated to use the orc::SymbolResolver API rather than the legacy llvm::JITSymbolResolver API. Because RuntimeDyld still uses JITSymbolResolver, this patch also includes an adapter that wraps an orc::SymbolResolver with a JITSymbolResolver API. llvm-svn: 323073
* [ORC] Add a lookupFlags method to VSO.Lang Hames2018-01-211-0/+20
| | | | | | | | | | | | lookupFlags returns a SymbolFlagsMap for the requested symbols, along with a set containing the SymbolStringPtr for any symbol not found in the VSO. The JITSymbolFlags for each symbol will have been stripped of its transient JIT-state flags (i.e. NotMaterialized, Materializing). Calling lookupFlags does not trigger symbol materialization. llvm-svn: 323060
* [ORC] More cleanup. NFC.Lang Hames2018-01-211-3/+3
| | | | llvm-svn: 323059
* [ORC] Cleanup. NFC.Lang Hames2018-01-211-2/+1
| | | | llvm-svn: 323057
* [ORC] Re-apply r322913 with a fix for a read-after-free error.Lang Hames2018-01-192-10/+9
| | | | | | | ExternalSymbolMap now stores the string key (rather than using a StringRef), as the object file backing the key may be removed at any time. llvm-svn: 323001
* [ORC] Revert r322913 while I investigate an ASan failure.Lang Hames2018-01-192-9/+10
| | | | llvm-svn: 322914
* [ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames2018-01-192-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose opportunities for parallel compilation. The two new query methods are lookupFlags, which finds the flags for each of a set of symbols; and lookup, which finds the address and flags for each of a set of symbols. (See doxygen comments for more details.) The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and modified to extend the new JITSymbolResolver class using the following scheme: - lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the symbols, then returning the result of calling getFlags() on each of these symbols. (Importantly: lookupFlags does NOT call getAddress on the returned symbols, so lookupFlags will never trigger materialization, and lookupFlags will never call findSymbol, so only symbols that are part of the logical dylib will return results.) - lookup is implemented by calling findSymbolInLogicalDylib for each symbol and falling back to findSymbol if findSymbolInLogicalDylib returns a null result. Assuming a symbol is found its getAddress method is called to materialize it and the result (if getAddress succeeds) is stored in the result map, or the error (if getAddress fails) is returned immediately from lookup. If any symbol is not found then lookup returns immediately with an error. This change will break any out-of-tree derivatives of JITSymbolResolver. This can be fixed by updating those classes to derive from LegacyJITSymbolResolver instead. llvm-svn: 322913
* [ExecutionEngine] Rename JITSymbol::isStrongDefinition to isStrong.Lang Hames2018-01-161-3/+3
| | | | | | For symmetry with isWeak, isCommon. llvm-svn: 322594
* [ORC] Add a stub ExecutionSession and VModuleKey type.Lang Hames2018-01-121-0/+6
| | | | | | | | | | ExecutionSession will represent a running JIT program. VModuleKey is a unique key assigned to each module added as part of an ExecutionSession. The Layer concept will be updated in future to require a VModuleKey when a module is added. llvm-svn: 322336
* [ORC] Re-apply r321838 again with a workaround for a bug present in the libcxxLang Hames2018-01-102-0/+318
| | | | | | | | | | | | | version being used on some of the green dragon builders (plus a clang-format). Workaround: AsynchronousSymbolQuery and VSO want to work with JITEvaluatedSymbols anyway, so just use them (instead of JITSymbol, which happens to tickle the bug). The libcxx bug being worked around was fixed in r276003, and there are plans to update the offending builders. llvm-svn: 322140
* [ORC] Remove AsynchronousSymbolQuery while I debug an issue on one of theLang Hames2018-01-062-85/+0
| | | | | | builders. llvm-svn: 321941
* [ORC] Yet more debugging output to diagnose test failures.Lang Hames2018-01-061-1/+4
| | | | llvm-svn: 321927
* [ORC] Temporarily adding some redundant asserts / debug output to aid inLang Hames2018-01-061-0/+14
| | | | | | debugging a tester failure. llvm-svn: 321920
* [ORC] Re-apply just the AsynchronousSymbolLookup class from r321838 while ILang Hames2018-01-053-2/+89
| | | | | | investigate builder / test failures. llvm-svn: 321910
* [ORC] Re-revert r321838: Tests are still failing.Lang Hames2018-01-053-345/+2
| | | | llvm-svn: 321858
* [ORC] Re-apply r321838 - Addition of new ORC core APIs.Lang Hames2018-01-053-2/+345
| | | | | | | | The original commit broke the builders due to a think-o in an assertion: AsynchronousSymbolQuery's constructor needs to check the callback member variables, not the constructor arguments. llvm-svn: 321853
* Revert r321838 -- It broke some of the builders.Lang Hames2018-01-053-344/+2
| | | | llvm-svn: 321842
* [ORC] Add new core ORC APIs (Core.h/Core.cpp): VSO, AsynchronousSymbolQuery andLang Hames2018-01-053-2/+344
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SymbolSource. These new APIs are a first stab at tackling some current shortcomings of ORC, especially in performance and threading support. VSO (Virtual Shared Object) is a symbol table representing the symbol definitions of a set of modules that behave as if they had been statically linked together into a shared object or dylib. Symbol definitions, either pre-defined addresses or lazy definitions, can be added and queries for symbol addresses made. The table applies the same linkage strength rules that static linkers do when constructing a dylib or shared object: duplicate definitions result in errors, strong definitions override weak or common ones. This class should improve symbol lookup speed by providing centralized symbol tables (as compared to the findSymbol implementation in the in-tree ORC layers, which maintain one symbol table per object file / module added). AsynchronousSymbolQuery is a query for the addresses of a set of symbols. Query results are returned via a callback once they become available. Querying for a set of symbols, rather than one symbol at a time (as the current lookup scheme does) the JIT has the opportunity to make better use of available resources (e.g. by spawning multiple jobs to materialize the requested symbols if possible). Returning results via a callback makes queries asynchronous, so queries from multiple threads of JIT'd code can proceed simultaneously. SymbolSource represents a source of symbol definitions. It is used when adding lazy symbol definitions to a VSO. Symbol definitions can be materialized when needed or discarded if a stronger definition is found. Materializing on demand via SymbolSources should (eventually) allow us to remove the lazy materializers from JITSymbol, which will in turn allow the removal of many current error checks and reduce the number of RPC round-trips involved in materializing remote symbols. Adding a discard function allows sources to discard symbol definitions (or mark them as available_externally), reducing the amount of redundant code generated by the JIT for ODR symbols. llvm-svn: 321838
* Remove redundant includes from lib/ExecutionEngine.Michael Zolotukhin2017-12-131-1/+0
| | | | llvm-svn: 320621
* [ORC] Fix the type of RTDyldObjectLinkingLayer::NotifyLoadedFtor.Lang Hames2017-09-281-1/+1
| | | | | | Bug found by Stefan Granitz. Thanks Stefan! llvm-svn: 314436
* [ORC] Hook up the LLVMOrcAddObjectFile function in the Orc C Bindings.Lang Hames2017-09-172-32/+92
| | | | | | This can be used to add a relocatable object to the JIT session. llvm-svn: 313474
* [ORC] Fix a typo.Lang Hames2017-09-151-1/+1
| | | | llvm-svn: 313346
* [ORC] Add a pair of ORC layers that forward object-layer operations via RPC.Lang Hames2017-09-051-0/+2
| | | | | | | | | | | | | | | | | This patch introduces RemoteObjectClientLayer and RemoteObjectServerLayer, which can be used to forward ORC object-layer operations from a JIT stack in the client to a JIT stack (consisting only of object-layers) in the server. This is a new way to support remote-JITing in LLVM. The previous approach (supported by OrcRemoteTargetClient and OrcRemoteTargetServer) used a remote-mapping memory manager that sat "beneath" the JIT stack and sent fully-relocated binary blobs to the server. The main advantage of the new approach is that relocatable objects can be cached on the server and re-used (if the code that they represent hasn't changed), whereas fully-relocated blobs can not (since the addresses they have been permanently bound to will change from run to run). llvm-svn: 312511
* [ORC] Add an Error return to the JITCompileCallbackManager::grow method.Lang Hames2017-09-031-6/+9
| | | | | | | | Calling grow may result in an error if, for example, this is a callback manager for a remote target. We need to be able to return this error to the callee. llvm-svn: 312429
* [Orc] Add a comment about member variable dependencies to OrcMCJITReplacement.Lang Hames2017-08-311-0/+3
| | | | | | | | | The comment explains the reason behind the change in member variable order in r312086. Thanks to Philip Reames for the suggestion. llvm-svn: 312205
* [Orc] Fix member variable ordering issue in OrcMCJITReplacement.Lang Hames2017-08-301-2/+3
| | | | | | | | | | | | | | | | https://reviews.llvm.org/D36888 From that review description: When an OrcMCJITReplacement object gets destructed, LazyEmitLayer may still contain a shared_ptr of a module, which requires ShouldDelete in the deleter. But ShouldDelete gets destructed before LazyEmitLayer due to the order of declaration in OrcMCJITReplacement, which leads to a crash, when the destructor of LazyEmitLayer is executed. Changing the order of declaration fixes this. Patch by Moritz Kroll. Thanks Moritz! llvm-svn: 312086
* Untabify.NAKAMURA Takumi2017-08-281-3/+3
| | | | llvm-svn: 311875
* [ORC] Add case statements for AArch64 to the local stub and callback managerLang Hames2017-08-151-0/+13
| | | | | | | | creation functions. This should allow lli to lazily execute code using OrcLazyJIT on AArch64. llvm-svn: 310938
* [ORC] Errorize the ORC APIs.Lang Hames2017-07-074-47/+116
| | | | | | | | This patch updates the ORC layers and utilities to return and propagate llvm::Errors where appropriate. This is necessary to allow ORC to safely handle error cases in cross-process and remote JITing. llvm-svn: 307350
* [Orc] Remove the memory manager argument to addModule, and de-templatize theLang Hames2017-07-042-12/+18
| | | | | | | | | | | | | | | | symbol resolver argument. De-templatizing the symbol resolver is part of the ongoing simplification of ORC layer API. Removing the memory management argument (and delegating construction of memory managers for RTDyldObjectLinkingLayer to a functor passed in to the constructor) allows us to build JITs whose base object layers need not be compatible with RTDyldObjectLinkingLayer's memory mangement scheme. For example, a 'remote object layer' that sends fully relocatable objects directly to the remote does not need a memory management scheme at all (that will be handled by the remote). llvm-svn: 307058
* Attempt to fix Orc JIT test timeoutsReid Kleckner2017-06-291-5/+5
| | | | | | | | | I think there are some destruction ordering issues here. The ShouldDelete map seems to be getting destroyed before the shared_ptr deleter lambda accesses it. In any case, this avoids inserting elements into the map during shutdown. llvm-svn: 306736
* [ORC] Re-apply r306166 and r306168 with fix for regression test.Lang Hames2017-06-234-27/+69
| | | | llvm-svn: 306182
* This reverts commit r306166 and r306168.Rafael Espindola2017-06-233-51/+27
| | | | | | | | | Revert "[ORC] Remove redundant semicolons from DEFINE_SIMPLE_CONVERSION_FUNCTIONS uses." Revert "[ORC] Move ORC IR layer interface from addModuleSet to addModule and fix the module type as std::shared_ptr<Module>." They broke ExecutionEngine/OrcMCJIT/test-global-ctors.ll on linux. llvm-svn: 306176
* [ORC] Remove redundant semicolons from DEFINE_SIMPLE_CONVERSION_FUNCTIONS uses.Lang Hames2017-06-231-2/+2
| | | | llvm-svn: 306168
* [ORC] Move ORC IR layer interface from addModuleSet to addModule and fix theLang Hames2017-06-233-27/+51
| | | | | | module type as std::shared_ptr<Module>. llvm-svn: 306166
* [ORC] Switch the object layer API from addObjectSet to addObject (singular), andLang Hames2017-06-222-42/+29
| | | | | | | | | move the ObjectCache from the IRCompileLayer to SimpleCompiler. This is the first in a series of patches aimed at cleaning up and improving the robustness and performance of the ORC APIs. llvm-svn: 306058
* [ExecutionEngine] Fix some Clang-tidy modernize-use-using and Include What ↵Eugene Zelenko2017-06-192-30/+53
| | | | | | You Use warnings; other minor fixes (NFC). llvm-svn: 305760
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-062-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
OpenPOWER on IntegriCloud