summaryrefslogtreecommitdiffstats
path: root/llvm/tools/lli/OrcLazyJIT.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Orc] Add lazy-JITting support for i386.Lang Hames2016-02-101-0/+11
| | | | | | | | | | | This patch adds a new class, OrcI386, which contains the hooks needed to support lazy-JITing on i386 (currently only for Pentium 2 or above, as the JIT re-entry code uses the FXSAVE/FXRSTOR instructions). Support for i386 is enabled in the LLI lazy JIT and the Orc C API, and regression and unit tests are enabled for this architecture. llvm-svn: 260338
* [Orc] Rename OrcTargetSupport to OrcArchitectureSupport to avoid confusion withLang Hames2016-01-111-1/+1
| | | | | | the upcoming remote-target support classes. llvm-svn: 257302
* [Orc] Rename IndirectStubsManagerBase to IndirectStubsManager.Lang Hames2015-12-061-1/+2
| | | | | | No functional change. llvm-svn: 254885
* [Orc] Rename JITCompileCallbackManagerBase to JITCompileCallbackManager.Lang Hames2015-12-041-1/+1
| | | | | | | | | This class is turning into a useful interface, rather than an implementation detail, so I'm dropping the 'Base' suffix. No functional change. llvm-svn: 254693
* Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block ↵Rafael Espindola2015-11-031-14/+8
| | | | | | | | | | and trampolines."" This reverts commit r251937. The test was updated to the new API, bring the API back. llvm-svn: 251944
* Revert "[Orc] Directly emit machine code for the x86 resolver block and ↵Rafael Espindola2015-11-031-8/+14
| | | | | | | | | | trampolines." This reverts commit r251933. It broke the build of examples/Kaleidoscope/Orc/fully_lazy/toy.cpp. llvm-svn: 251937
* [Orc] Directly emit machine code for the x86 resolver block and trampolines.Lang Hames2015-11-031-14/+8
| | | | | | | | | | | | | | Bypassing LLVM for this has a number of benefits: 1) Laziness support becomes asm-syntax agnostic (previously lazy jitting didn't work on Windows as the resolver block was in Darwin asm). 2) For cross-process JITs, it allows resolver blocks and trampolines to be emitted directly in the target process, reducing cross process traffic. 3) It should be marginally faster. llvm-svn: 251933
* [Orc] Add support for emitting indirect stubs directly into the JIT target'sLang Hames2015-10-191-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | memory, rather than representing the stubs in IR. Update the CompileOnDemand layer to use this functionality. Directly emitting stubs is much cheaper than building them in IR and codegen'ing them (see below). It also plays well with remote JITing - stubs can be emitted directly in the target process, rather than having to send them over the wire. The downsides are: (1) Care must be taken when resolving symbols, as stub symbols are held in a separate symbol table. This is only a problem for layer writers and other people using this API directly. The CompileOnDemand layer hides this detail. (2) Aliases of function stubs can't be symbolic any more (since there's no symbol definition in IR), but must be converted into a constant pointer expression. This means that modules containing aliases of stubs cannot be cached. In practice this is unlikely to be a problem: There's no benefit to caching such a module anyway. On balance I think the extra performance is more than worth the trade-offs: In a simple stress test with 10000 dummy functions requiring stubs and a single executed "hello world" main function, directly emitting stubs reduced user time for JITing / executing by over 90% (1.5s for IR stubs vs 0.1s for direct emission). llvm-svn: 250712
* Fix lli with OrcLazyJIT: the default DataLayout was used.Mehdi Amini2015-07-301-0/+1
| | | | | | | Set the correct one using the TargetMachine instead. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243664
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243114
* Revert "Remove access to the DataLayout in the TargetMachine"Mehdi Amini2015-07-241-2/+1
| | | | | | | | | | This reverts commit 0f720d984f419c747709462f7476dff962c0bc41. It breaks clang too badly, I need to prepare a proper patch for clang first. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243089
* Remove access to the DataLayout in the TargetMachineMehdi Amini2015-07-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Replace getDataLayout() with a createDataLayout() method to make explicit that it is intended to create a DataLayout only and not accessing it for other purpose. This change is the last of a series of commits dedicated to have a single DataLayout during compilation by using always the one owned by the module. Reviewers: echristo Subscribers: jholewinski, llvm-commits, rafael, yaron.keren Differential Revision: http://reviews.llvm.org/D11103 (cherry picked from commit 5609fc56bca971e5a7efeaa6ca4676638eaec5ea) From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 243083
* Replace string GNU Triples with llvm::Triple in ↵Daniel Sanders2015-06-161-1/+1
| | | | | | | | | | | | | | | | | | TargetMachine::getTargetTriple(). NFC. Summary: This continues the patch series to eliminate StringRef forms of GNU triples from the internals of LLVM that began in r239036. Reviewers: rengolin Reviewed By: rengolin Subscribers: llvm-commits, rengolin Differential Revision: http://reviews.llvm.org/D10381 llvm-svn: 239815
* [lli] Make the OptLevel (-O=<char>) option accessible to the lazy JIT.Lang Hames2015-06-091-1/+6
| | | | | | No test case - this only affects generated code performance. llvm-svn: 239383
* Fix -Wpessimizing-move warnings by removing std::move calls.Richard Trieu2015-04-301-4/+4
| | | | llvm-svn: 236278
* lli/OrcLazyJIT.cpp: Use <cstdio> for printf(3) introduced in r234908.NAKAMURA Takumi2015-04-171-0/+1
| | | | llvm-svn: 235175
* [Orc] Reapply r234815, outputting via stdout instead.Lang Hames2015-04-141-11/+12
| | | | llvm-svn: 234908
* Silencing a -Wreturn-type warning, as the switch is fully-covered; NFC.Aaron Ballman2015-04-141-0/+1
| | | | llvm-svn: 234884
* [Orc] Disambiguate call to make_unique. This should fix the builders broken byLang Hames2015-04-131-1/+2
| | | | | | r234805. llvm-svn: 234806
* [Orc] Add an Orc layer for applying arbitrary transforms to IR, use it to addLang Hames2015-04-131-3/+78
| | | | | | | debugging output to the LLI orc-lazy JIT, and update the orc-lazy "hello.ll" test to actually test for lazy compilation. llvm-svn: 234805
* [Orc] Add support classes for inspecting and running C++ static ctor/dtors, andLang Hames2015-04-021-3/+1
| | | | | | | | | use these to add support for C++ static ctors/dtors to the Orc-lazy JIT in LLI. Replace the trivial_retval_1 regression test - the new 'hello' test is covering strictly more code. llvm-svn: 233885
* [Orc] Reflect process symbols into the LLI Orc-lazy JIT.Lang Hames2015-04-011-0/+13
| | | | | | | This makes symbol resolution essentially identical between MCJIT and the LLI Orc-lazy JIT. llvm-svn: 233786
* [Orc] Separate callback manager selection from callback manager construction forLang Hames2015-03-301-12/+17
| | | | | | | | OrcLazyJIT in lli. Separating these concerns enables more natural error handling. llvm-svn: 233579
* [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo throughLang Hames2015-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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][lli] Add a very simple Orc-based lazy JIT to lli.Lang Hames2015-03-251-0/+53
This ensures that we're building and testing the CompileOnDemand layer, at least in a basic way. Currently x86-64 only, and with limited to no library calls enabled (depending on host platform). Patches welcome. ;) To enable access to the lazy JIT, this patch replaces the '-use-orcmcjit' lli option with a new option: '-jit-kind={ mcjit | orc-mcjit | orc-lazy }'. All regression tests are updated to use the new option, and one trivial test of the new lazy JIT is added. llvm-svn: 233182
OpenPOWER on IntegriCloud