summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Add deprecation warnings to ORCv1 layers and utilities.Lang Hames2019-07-171-5/+5
| | | | | | | | | | | | | | | | | Summary: ORCv1 is deprecated. The current aim is to remove it before the LLVM 10.0 release. This patch adds deprecation attributes to the ORCv1 layers and utilities to warn clients of the change. Reviewers: dblaikie, sgraenitz, AlexDenisov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64609 llvm-svn: 366344
* [ORC] Update symbol lookup to use a single callback with a required symbol stateLang Hames2019-06-071-9/+6
| | | | | | | | | | | | | | | | | | | | | | | 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
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* [ORC] Rename ORC layers to make the "new" ORC layers the default.Lang Hames2018-10-151-2/+2
| | | | | | | | | | | | | 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
* [MIPS] ORC JIT supportPetar Jovanovic2018-09-111-2/+2
| | | | | | | | | | | | 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] Replace lookupFlags in JITSymbolResolver with getResponsibilitySet.Lang Hames2018-08-281-8/+11
| | | | | | | | | | | | | | 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
* Re-apply r337595 with fix for LLVM_ENABLE_THREADS=Off.Lang Hames2018-07-201-4/+4
| | | | llvm-svn: 337626
* Revert r337595 "[ORC] Add new symbol lookup methods to ExecutionSessionBase ↵Reid Kleckner2018-07-201-4/+4
| | | | | | | | 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-201-4/+4
| | | | | | | | | | | | 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-201-8/+6
| | | | | | | | | | | 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] Refactor blocking lookup logic into the blockingLookup function, andLang Hames2018-06-121-0/+5
| | | | | | | implement existing blocking lookups (the lookup function) and JITSymbolResolverAdapter on top of that. llvm-svn: 334537
* [ORC] Extend object layer callbacks so JITEventListener can be supported.Andres Freund2018-05-241-1/+4
| | | | | | | | | | | | | | | | | | | | | | Currently RTDyldObjectLinkingLayer makes it hard to support JITEventListeners. Which in turn means debugging and profiling JIT generated code hard. Supporting JITEventListeners at minimum requries a freed callback (added). As listeners expect the ObjectFile to be passed as well, an adaptor between RTDyldObjectLinkingLayer and JITEventListeners would currently need to also maintain ObjectFiles for all loaded modules. To make that less awkward, extend the callbacks to pass the ObjectFile to both Finalized and Freed callbacks. That requires extending the lifetime of the object file when callbacks are present. Reviewed By: lhames Differential Revision: https://reviews.llvm.org/D44890 llvm-svn: 333227
* [ORC] Rewrite the VSO symbol table yet again. Update related utilities.Lang Hames2018-05-161-8/+14
| | | | | | | | | | | | | | | | | | | VSOs now track dependencies for materializing symbols. Each symbol must have its dependencies registered with the VSO prior to finalization. Usually this will involve registering the dependencies returned in AsynchronousSymbolQuery::ResolutionResults for queries made while linking the symbols being materialized. Queries against symbols are notified that a symbol is ready once it and all of its transitive dependencies are finalized, allowing compilation work to be broken up and moved between threads without queries returning until their symbols fully safe to access / execute. Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are updated to support dependence tracking and more explicitly track responsibility for symbols from the point of definition until they are finalized. llvm-svn: 332541
* [ORC] Add a MaterializationResponsibility class to track responsibility forLang Hames2018-04-161-4/+4
| | | | | | | | | | | | | | | | | materializing function definitions. MaterializationUnit instances are responsible for resolving and finalizing symbol definitions when their materialize method is called. By contract, the MaterializationUnit must materialize all definitions it is responsible for and no others. If it can not materialize all definitions (because of some error) then it must notify the associated VSO about each definition that could not be materialized. The MaterializationResponsibility class tracks this responsibility, asserting that all required symbols are resolved and finalized, and that no extraneous symbols are resolved or finalized. In the event of an error it provides a convenience method for notifying the VSO about each definition that could not be materialized. llvm-svn: 330142
* [ORC] Plumb error notifications through the VSO interface.Lang Hames2018-04-121-7/+6
| | | | | | | This allows materializers to notify the VSO that they were unable to resolve or finalize symbols. llvm-svn: 329934
* [ORC] Create a new SymbolStringPool by default in ExecutionSession constructor.Lang Hames2018-04-021-2/+2
| | | | | | This makes the common case of constructing an ExecutionSession tidier. llvm-svn: 329013
* [ORC] Re-apply r327566 with a fix for test-global-ctors.ll.Lang Hames2018-03-151-23/+50
| | | | | | Also clang-formats the patch, which I should have done the first time around. llvm-svn: 327594
* Revert "[ORC] Switch from shared_ptr to unique_ptr for addModule methods."Reid Kleckner2018-03-141-14/+20
| | | | | | | | | | | | | This reverts commit r327566, it breaks test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll. The test doesn't crash with a stack trace, unfortunately. It merely returns 1 as the exit code. ASan didn't produce a report, and I reproduced this on my Linux machine and Windows box. llvm-svn: 327576
* [ORC] Switch from shared_ptr to unique_ptr for addModule methods.Lang Hames2018-03-141-20/+14
| | | | | | | Layer implementations typically mutate module state, and this is better reflected by having layers own the Module they are operating on. llvm-svn: 327566
* [ORC] Switch RTDyldObjectLinkingLayer to take a unique_ptr<MemoryBuffer> ratherLang Hames2018-02-211-16/+11
| | | | | | | | | | 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-141-3/+6
| | | | | | | | | 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-141-8/+8
| | | | | | | 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-091-13/+4
| | | | | | | | | 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] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames2018-02-061-17/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Re-apply r322913 with a fix for a read-after-free error.Lang Hames2018-01-191-9/+8
| | | | | | | 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-191-8/+9
| | | | llvm-svn: 322914
* [ORC] Redesign the JITSymbolResolver interface to support bulk queries.Lang Hames2018-01-191-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ORC] Fix the type of RTDyldObjectLinkingLayer::NotifyLoadedFtor.Lang Hames2017-09-281-1/+1
| | | | | | Bug found by Stefan Granitz. Thanks Stefan! llvm-svn: 314436
* [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] Errorize the ORC APIs.Lang Hames2017-07-071-5/+5
| | | | | | | | 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-041-9/+12
| | | | | | | | | | | | | | | | 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-231-4/+24
| | | | llvm-svn: 306182
* This reverts commit r306166 and r306168.Rafael Espindola2017-06-231-11/+4
| | | | | | | | | 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] Move ORC IR layer interface from addModuleSet to addModule and fix theLang Hames2017-06-231-4/+11
| | | | | | module type as std::shared_ptr<Module>. llvm-svn: 306166
* [ORC] Switch the object layer API from addObjectSet to addObject (singular), andLang Hames2017-06-221-39/+25
| | | | | | | | | 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-191-13/+18
| | | | | | You Use warnings; other minor fixes (NFC). llvm-svn: 305760
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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] Rename ObjectLinkingLayer -> RTDyldObjectLinkingLayer.Lang Hames2017-02-201-4/+4
| | | | | | | | | | 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
* 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
* 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-011-11/+10
| | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud