summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/MCJIT/MCJIT.h
Commit message (Collapse)AuthorAgeFilesLines
* [MCJIT] Add a FindGlobalVariableNamed utilityKeno Fischer2015-06-201-2/+12
| | | | | | | | | | | | | | | | Summary: This adds FindGlobalVariableNamed to ExecutionEngine (plus implementation in MCJIT), which is an analog of FindFunctionNamed for GlobalVariables. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10421 llvm-svn: 240202
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-191-1/+1
| | | | | | | | | | | | | The patch is generated using this command: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ llvm/lib/ Thanks to Eugene Kosov for the original patch! llvm-svn: 240137
* [ExecutionEngine] ArrayRefize argument passing.Benjamin Kramer2015-06-131-1/+1
| | | | | | No functionality change intended. llvm-svn: 239687
* Use 'override/final' instead of 'virtual' for overridden methodsAlexander Kornienko2015-04-111-1/+1
| | | | | | | | | | | | | | The patch is generated using clang-tidy misc-use-override check. This command was used: tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \ -checks='-*,misc-use-override' -header-filter='llvm|clang' \ -j=32 -fix -format http://reviews.llvm.org/D8925 llvm-svn: 234679
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-55/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MCJIT. This patch decouples the two responsibilities of the RTDyldMemoryManager class, memory management and symbol resolution, into two new classes: RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver. The symbol resolution interface is modified slightly, from: uint64_t getSymbolAddress(const std::string &Name); to: RuntimeDyld::SymbolInfo findSymbol(const std::string &Name); The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld and others to reason about non-strong/non-exported symbols. The memory management interface removes the following method: void notifyObjectLoaded(ExecutionEngine *EE, const object::ObjectFile &) {} as it is not related to memory management. (Note: Backwards compatibility *is* maintained for this method in MCJIT and OrcMCJITReplacement, see below). The RTDyldMemoryManager class remains in-tree for backwards compatibility. It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which just subclasses RuntimeDyld::MemoryManager and reintroduces the notifyObjectLoaded method for backwards compatibility). The EngineBuilder class retains the existing method: EngineBuilder& setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm); and includes two new methods: EngineBuilder& setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM); EngineBuilder& setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR); Clients should use EITHER: A single call to setMCJITMemoryManager with an RTDyldMemoryManager. OR (exclusive) One call each to each of setMemoryManager and setSymbolResolver. This patch should be fully compatible with existing uses of RTDyldMemoryManager. If it is not it should be considered a bug, and the patch either fixed or reverted. If clients find the new API to be an improvement the goal will be to deprecate and eventually remove the RTDyldMemoryManager class in favor of the new classes. llvm-svn: 233509
* [Orc] New JIT APIs.Lang Hames2015-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new set of JIT APIs to LLVM. The aim of these new APIs is to cleanly support a wider range of JIT use cases in LLVM, and encourage the development and contribution of re-usable infrastructure for LLVM JIT use-cases. These APIs are intended to live alongside the MCJIT APIs, and should not affect existing clients. Included in this patch: 1) New headers in include/llvm/ExecutionEngine/Orc that provide a set of components for building JIT infrastructure. Implementation code for these headers lives in lib/ExecutionEngine/Orc. 2) A prototype re-implementation of MCJIT (OrcMCJITReplacement) built out of the new components. 3) Minor changes to RTDyldMemoryManager needed to support the new components. These changes should not impact existing clients. 4) A new flag for lli, -use-orcmcjit, which will cause lli to use the OrcMCJITReplacement class as its underlying execution engine, rather than MCJIT itself. Tests to follow shortly. Special thanks to Michael Ilseman, Pete Cooper, David Blaikie, Eric Christopher, Justin Bogner, and Jim Grosbach for extensive feedback and discussion. llvm-svn: 226940
* [MCJIT] Unique-ptrify the RTDyldMemoryManager member of MCJIT. NFC.Lang Hames2014-12-031-4/+5
| | | | llvm-svn: 223183
* [MCJIT] Reapply r222828 and r222810-r222812 with fix for MSVC move-op issues.Lang Hames2014-11-261-6/+7
| | | | llvm-svn: 222840
* Reverting r222828 and r222810-r222812 as they broke the build on Windows.Aaron Ballman2014-11-261-7/+6
| | | | | | http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753 llvm-svn: 222833
* [MCJIT] Clean up RuntimeDyld's quirky object-ownership/modification scheme.Lang Hames2014-11-261-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, when loading an object file, RuntimeDyld (1) took ownership of the ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the object in-place, and (3) returned an ObjectImage that managed ownership of the now-modified object and provided some convenience methods. This scheme accreted over several years as features were tacked on to RuntimeDyld, and was both unintuitive and unsafe (See e.g. http://llvm.org/PR20722). This patch fixes the issue by removing all ownership and in-place modification of object files from RuntimeDyld. Existing behavior, including debugger registration, is preserved. Noteworthy changes include: (1) ObjectFile instances are now passed to RuntimeDyld by const-ref. (2) The ObjectImage and ObjectBuffer classes have been removed entirely, they existed to model ownership within RuntimeDyld, and so are no longer needed. (3) RuntimeDyld::loadObject now returns an instance of a new class, RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified object suitable for registration with the debugger, following the existing debugger registration scheme. (4) The JITRegistrar class has been removed, and the GDBRegistrar class has been re-written as a JITEventListener. This should fix http://llvm.org/PR20722 . llvm-svn: 222810
* [MCJIT] Start Stringref-izing the ExecutionEngine interface.Lang Hames2014-09-151-1/+1
| | | | | | | | | More methods to follow. Using StringRef allows us the EE interface to work with more string types without forcing construction of std::strings. llvm-svn: 217794
* [MCJIT] Fix an iterator invalidation bug in MCJIT::finalizeObject.Lang Hames2014-09-051-0/+3
| | | | | | | | | | | The finalizeObject method calls generateCodeForModule on each of the currently 'added' objects, but generateCodeForModule moves objects out of the 'added' set as it's called. To avoid iterator invalidation issues, the added set is copied out before any calls to generateCodeForModule. This should fix http://llvm.org/PR20851 . llvm-svn: 217291
* unique_ptrify MCJIT::emitObjectDavid Blaikie2014-09-031-1/+1
| | | | llvm-svn: 217067
* unique_ptrify a bunch of stuff through RuntimeDyld::loadObjectDavid Blaikie2014-09-031-2/+1
| | | | llvm-svn: 217065
* unique_ptrify passing the TargetMachine to ExecutionEngine::MCJITCtorDavid Blaikie2014-09-021-4/+4
| | | | llvm-svn: 216988
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-021-7/+1
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* Give ExecutionEngine of top level buffers.Rafael Espindola2014-08-261-0/+2
| | | | | | | Long term the idea if for the engine to not own the buffers, but for now this is consistent with the rest of the API. llvm-svn: 216484
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola2014-08-191-5/+6
| | | | llvm-svn: 215967
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-131-2/+2
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-071-1/+7
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* Nuke the old JIT.Rafael Espindola2014-08-071-7/+1
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Replace comment about ownership with std::unique_ptr.Rafael Espindola2014-08-011-2/+2
| | | | llvm-svn: 214533
* Delete dead code.Rafael Espindola2014-07-311-3/+1
| | | | llvm-svn: 214370
* PR19553: Memory leak in RuntimeDyldELF::createObjectImageFromFileDavid Blaikie2014-04-291-1/+1
| | | | | | | | | | | | | | | | This starts in MCJIT::getSymbolAddress where the unique_ptr<object::Binary> is release()d and (after a cast) passed to a single caller, MCJIT::addObjectFile. addObjectFile calls RuntimeDyld::loadObject. RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile And the pointer is never owned at this point. I say this point, because the alternative codepath, RuntimeDyldMachO::createObjectFile certainly does take ownership, so this seemed like a good hint that this was a/the right place to take ownership. llvm-svn: 207580
* [C++] Use 'nullptr'.Craig Topper2014-04-281-1/+1
| | | | llvm-svn: 207394
* Add an option to MCJIT to have it forward all sections to theLang Hames2014-03-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | RTDyldMemoryManager, regardless of whether it thinks they're "required for execution". Currently, RuntimeDyld only passes sections that are "required for execution" to the RTDyldMemoryManager, and takes "required for execution" to mean exactly "contains symbols or relocations". There are two problems with this: (1) It can drop sections with anonymous data that is referenced by code. (2) It leaves the JIT client no way to inspect interesting sections that aren't actually required to run the program (e.g dwarf sections). A test case is still in the works. Future work: We may want to replace this with a generic section filtering mechanism, but that will require more consideration. For now, this flag at least allows clients to volunteer to do the filtering themselves. Fixes <rdar://problem/15177691>. llvm-svn: 204398
* [C++11] Add 'override' keyword to virtual methods that override their base ↵Craig Topper2014-03-081-42/+43
| | | | | | class. llvm-svn: 203344
* Replace OwningPtr<T> with std::unique_ptr<T>.Ahmed Charles2014-03-061-1/+1
| | | | | | | | | | This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
* Extend RTDyld API to enable optionally precomputing the total amount of memoryLang Hames2014-02-121-0/+9
| | | | | | | | | | | | | | | | | | required for all sections in a module. This can be useful when targets or code-models place strict requirements on how sections must be laid out in memory. If RTDyldMemoryManger::needsToReserveAllocationSpace() is overridden to return true then the JIT will call the following method on the memory manager, which can be used to preallocate the necessary memory. void RTDyldMemoryManager::reserveAllocationSpace(uintptr_t CodeSize, uintptr_t DataSizeRO, uintptr_t DataSizeRW) Patch by Vaidas Gasiunas. Thanks very much Viadas! llvm-svn: 201259
* Add target analysis passes to the codegen pipeline for MCJIT.Juergen Ributzka2014-01-231-0/+2
| | | | | | | | | | | This patch adds the target analysis passes (usually TargetTransformInfo) to the codgen pipeline. We also expose now the AddAnalysisPasses method through the C API, because the optimizer passes would also benefit from better target-specific cost models. Reviewed by Andrew Kaylor llvm-svn: 199926
* Re-apply r196639: Add support for archives and object file caching under MCJIT.Lang Hames2014-01-081-2/+6
| | | | | | | | | I believe the bot failures on linux systems were due to overestimating the alignment of object-files within archives, which are only guaranteed to be two-byte aligned. I have reduced the alignment in RuntimeDyldELF::createObjectImageFromFile accordingly. llvm-svn: 198737
* Whitespace cleanups.NAKAMURA Takumi2013-12-071-1/+1
| | | | llvm-svn: 196654
* Revert r196639 while I investigate a bot failure.Lang Hames2013-12-071-6/+2
| | | | llvm-svn: 196641
* Add support for archives and object file caching under MCJIT.Lang Hames2013-12-071-2/+6
| | | | | | Patch by Andy Kaylor, with minor edits to resolve merge conflicts. llvm-svn: 196639
* Replaced non-ASCII character.Yaron Keren2013-10-241-1/+1
| | | | llvm-svn: 193324
* Optimizing MCJIT module state trackingAndrew Kaylor2013-10-241-22/+122
| | | | | | Patch co-developed with Yaron Keren. llvm-svn: 193291
* FIXME comment shouldn't have been doxygen styleAndrew Kaylor2013-10-211-1/+1
| | | | llvm-svn: 193131
* Improving MCJIT/RuntimeDyld thread safetyAndrew Kaylor2013-10-211-4/+0
| | | | llvm-svn: 193094
* Added comments from Andrew Kaylor.Yaron Keren2013-10-191-0/+21
| | | | llvm-svn: 193033
* Adding support for deregistering EH frames with MCJIT.Andrew Kaylor2013-10-161-0/+6
| | | | | | Patch by Yaron Keren llvm-svn: 192753
* Adding multiple object support to MCJIT EH frame handlingAndrew Kaylor2013-10-111-2/+2
| | | | llvm-svn: 192504
* Adding support and tests for multiple module handling in lliAndrew Kaylor2013-10-041-0/+5
| | | | llvm-svn: 191938
* This threads SectionName through the allocateCodeSection/allocateDataSection ↵Filip Pizlo2013-10-021-4/+5
| | | | | | | | | | | | | | | | | | APIs, both in C++ and C land. It's useful for the memory managers that are allocating a section to know what the name of the section is. At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about what each allocation is for. This allows clients that supply their own memory managers to do this. Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM client. This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory management C API). llvm-svn: 191804
* Adding multiple module support for MCJIT.Andrew Kaylor2013-10-011-9/+89
| | | | | | | | Tests to follow. PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support. llvm-svn: 191722
* Minor changes to the MCJITTest unittests to use the correct API for finalizingDavid Tweed2013-05-171-0/+7
| | | | | | | the JIT object (including XFAIL an ARM test that now needs fixing). Also renames internal function for consistency. llvm-svn: 182085
* SectionMemoryManager shouldn't be a JITMemoryManager. Previously, the Filip Pizlo2013-05-141-1/+1
| | | | | | | | | | | | | | | | | EngineBuilder interface required a JITMemoryManager even if it was being used to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager. Consequently, the SectionMemoryManager, which is meant for MCJIT, derived from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager methods that weren't relevant to the MCJIT. This patch fixes the situation: it teaches the EngineBuilder that RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if we're using the MCJIT. This allows us to remove the stub methods from SectionMemoryManager, and make SectionMemoryManager a direct subtype of RTDyldMemoryManager. llvm-svn: 181820
* Re-enabling MCJIT object caching with memory leak fixedAndrew Kaylor2013-04-251-2/+12
| | | | llvm-svn: 180575
* Revert "Adding object caching support to MCJIT"Rafael Espindola2013-04-251-12/+2
| | | | | | | | | | This reverts commit 07f03923137a91e3cca5d7fc075a22f8c9baf33a. Looks like it broke the valgrind bot: http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak/builds/649 llvm-svn: 180249
* Adding object caching support to MCJITAndrew Kaylor2013-04-231-2/+12
| | | | llvm-svn: 180146
OpenPOWER on IntegriCloud