summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc
Commit message (Collapse)AuthorAgeFilesLines
...
* [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
* [ExecutionEngine] Make RuntimeDyld::MemoryManager responsible for tracking EHLang Hames2017-05-091-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | frames. RuntimeDyld was previously responsible for tracking allocated EH frames, but it makes more sense to have the RuntimeDyld::MemoryManager track them (since the frames are allocated through the memory manager, and written to memory owned by the memory manager). This patch moves the frame tracking into RTDyldMemoryManager, and changes the deregisterFrames method on RuntimeDyld::MemoryManager from: void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t Size); to: void deregisterEHFrames(); Separating this responsibility will allow ORC to continue to throw the RuntimeDyld instances away post-link (saving a few dozen bytes per lazy function) while properly deregistering frames when modules are unloaded. This patch also updates ORC to call deregisterEHFrames when modules are unloaded. This fixes a bug where an exception that tears down the JIT can then unwind through dangling EH frames that have been deallocated but not deregistered, resulting in UB. For people using SectionMemoryManager this should be pretty much a no-op. For people with custom allocators that override registerEHFrames/deregisterEHFrames, you will now be responsible for tracking allocated EH frames. Reviewed in https://reviews.llvm.org/D32829 llvm-svn: 302589
* [ORC] Add RPC and serialization support for Errors and Expecteds.Lang Hames2017-04-131-0/+3
| | | | | | | | | | | | | | This patch allows Error and Expected types to be passed to and returned from RPC functions. Serializers and deserializers for custom error types (types deriving from the ErrorInfo class template) can be registered with the SerializationTraits for a given channel type (see registerStringError in RPCSerialization.h for an example), allowing a given custom type to be sent/received. Unregistered types will be serialized/deserialized as StringErrors using the custom type's log message as the error string. llvm-svn: 300167
* [ORC] Add missing file from r300155.Lang Hames2017-04-131-0/+55
| | | | llvm-svn: 300157
* [ORC] Use native Errors rather than converted std::error_codes for ORC RPC.Lang Hames2017-04-132-19/+5
| | | | llvm-svn: 300155
* [Orc] Make orcError return an error_code rather than Error.Lang Hames2017-04-061-6/+3
| | | | | | | This will allow orcError to be used in convertToErrorCode implementations, which will help in transitioning Orc RPC to Error. llvm-svn: 299610
* [Orc] Rename ObjectLinkingLayer -> RTDyldObjectLinkingLayer.Lang Hames2017-02-202-6/+6
| | | | | | | | | | The current ObjectLinkingLayer (now RTDyldObjectLinkingLayer) links objects in-process using MCJIT's RuntimeDyld class. In the near future I hope to add new object linking layers (e.g. a remote linking layer that links objects in the JIT target process, rather than the client), so I'm renaming this class to be more descriptive. llvm-svn: 295636
* [Orc][RPC] Add an RPCFunctionNotSupported error type and return it fromLang Hames2017-01-151-0/+20
| | | | | | | | | | negotiateFunction where appropriate. Replacing the old ECError with a custom type allows us to attach the name of the function that could not be negotiated, enabling better diagnostics for negotiation failures. llvm-svn: 292055
* [Orc][RPC] Add a ParallelCallGroup utility for dispatching and waiting onLang Hames2016-12-251-0/+2
| | | | | | | | | | | | | | | | multiple asynchronous RPC calls. ParallelCallGroup allows multiple asynchronous calls to be dispatched, and provides a wait method that blocks until all asynchronous calls have been executed on the remote and all return value handlers run on the local machine. This will allow, for example, the JIT client to issue memory allocation calls for all sections in parallel, then block until all memory has been allocated on the remote and the allocated addresses registered with the client, at which point the JIT client can proceed to applying relocations. llvm-svn: 290523
* Fix some Clang-tidy and Include What You Use warnings; other minor fixes (NFC).Eugene Zelenko2016-11-301-5/+26
| | | | | | This preparation to remove SetVector.h dependency on SmallSet.h. llvm-svn: 288256
* [ORC] Re-apply 286620 with fixes for the ErrorSuccess class.Lang Hames2016-11-113-54/+2
| | | | llvm-svn: 286639
* [ORC] Revert r286620 while I investigate a bot failure.Lang Hames2016-11-113-2/+54
| | | | llvm-svn: 286621
* [ORC] Refactor the ORC RPC utilities to add some new features.Lang Hames2016-11-113-54/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (1) Add support for function key negotiation. The previous version of the RPC required both sides to maintain the same enumeration for functions in the API. This means that any version skew between the client and server would result in communication failure. With this version of the patch functions (and serializable types) are defined with string names, and the derived function signature strings are used to negotiate the actual function keys (which are used for efficient call serialization). This allows clients to connect to any server that supports a superset of the API (based on the function signatures it supports). (2) Add a callAsync primitive. The callAsync primitive can be used to install a return value handler that will run as soon as the RPC function's return value is sent back from the remote. (3) Launch policies for RPC function handlers. The new addHandler method, which installs handlers for RPC functions, takes two arguments: (1) the handler itself, and (2) an optional "launch policy". When the RPC function is called, the launch policy (if present) is invoked to actually launch the handler. This allows the handler to be spawned on a background thread, or added to a work list. If no launch policy is used, the handler is run on the server thread itself. This should only be used for short-running handlers, or entirely synchronous RPC APIs. (4) Zero cost cross type serialization. You can now define serialization from any type to a different "wire" type. For example, this allows you to call an RPC function that's defined to take a std::string while passing a StringRef argument. If a serializer from StringRef to std::string has been defined for the channel type this will be used to serialize the argument without having to construct a std::string instance. This allows buffer reference types to be used as arguments to RPC calls without requiring a copy of the buffer to be made. llvm-svn: 286620
* Remove LLVM_NOEXCEPT and replace it with noexceptReid Kleckner2016-10-191-1/+1
| | | | | | | Now that we have dropped MSVC 2013, all supported compilers support noexcept and we can drop this portability macro. llvm-svn: 284672
* [ORC] Clone module flags metadata into the globals module in theLang Hames2016-09-041-0/+9
| | | | | | | | CompileOnDemandLayer. Also contains a tweak to the orc-lazy jit in LLI to enable the test case. llvm-svn: 280632
* Re-apply r278065 (Weak symbol support in RuntimeDyld) with a fix for ELF.Lang Hames2016-08-091-2/+4
| | | | llvm-svn: 278149
* Revert r278065 while I investigate some build-bot breakage.Lang Hames2016-08-081-4/+2
| | | | llvm-svn: 278069
* [RuntimeDyld][Orc][MCJIT] Add partial weak-symbol support to RuntimeDyld.Lang Hames2016-08-081-2/+4
| | | | | | | | | | | | | | | This patch causes RuntimeDyld to check for existing definitions when it encounters weak symbols. If a definition already exists then the new weak definition is discarded. All symbol lookups within a "logical dylib" should now agree on the address of any given weak symbol. This allows the JIT to better match the behavior of the static linker for C++ code. This support is only partial, as it does not allow strong definitions that occur after the first weak definition (in JIT symbol lookup order) to override the previous weak definitions. Support for this will be added in a future patch. llvm-svn: 278065
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-014-34/+33
| | | | | | | | | | | | | | | | This patch replaces RuntimeDyld::SymbolInfo with JITSymbol: A symbol class that is capable of lazy materialization (i.e. the symbol definition needn't be emitted until the address is requested). This can be used to support common and weak symbols in the JIT (though this is not implemented in this patch). For consistency, RuntimeDyld::SymbolResolver is renamed to JITSymbolResolver. For space efficiency a new class, JITEvaluatedSymbol, is introduced that behaves like the old RuntimeDyld::SymbolInfo - i.e. it is just a pair of an address and symbol flags. Instances of JITEvaluatedSymbol can be used in symbol-tables to avoid paying the space cost of the materializer. llvm-svn: 277386
* [Object] Change Archive::findSym to return an Expected<Optional<Child>>.Lang Hames2016-07-141-6/+6
| | | | | | | As suggested by Rafael in review of D22079 - this was accidentally left out of the final commit (r275316). llvm-svn: 275469
* [Object] Re-apply r275316 now that I have the corresponding LLD patch ready.Lang Hames2016-07-141-4/+5
| | | | llvm-svn: 275361
* [Object] Revert r275316, Archive::child_iterator changes, while I update lld.Lang Hames2016-07-141-5/+4
| | | | | | Should fix the bots broken by r275316. llvm-svn: 275353
* [Object] Change Archive::child_iterator for better interop with Error/Expected.Lang Hames2016-07-131-4/+5
| | | | | | | | | | | | | | | | | | | | | | | See http://reviews.llvm.org/D22079 Changes the Archive::child_begin and Archive::children to require a reference to an Error. If iterator increment fails (because the archive header is damaged) the iterator will be set to 'end()', and the error stored in the given Error&. The Error value should be checked by the user immediately after the loop. E.g.: Error Err; for (auto &C : A->children(Err)) { // Do something with archive child C. } // Check the error immediately after the loop. if (Err) return Err; Failure to check the Error will result in an abort() when the Error goes out of scope (as guaranteed by the Error class). llvm-svn: 275316
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+3
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
OpenPOWER on IntegriCloud