summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc/OrcTargetSupport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Orc] Rename OrcTargetSupport to OrcArchitectureSupport to avoid confusion withLang Hames2016-01-111-171/+0
| | | | | | the upcoming remote-target support classes. llvm-svn: 257302
* Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block ↵Rafael Espindola2015-11-031-122/+74
| | | | | | | | | | 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-74/+122
| | | | | | | | | | 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-122/+74
| | | | | | | | | | | | | | 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
* Add a sys::OwningMemoryBlock class, which is a sys::MemoryBlock that owns itsLang Hames2015-10-311-31/+10
| | | | | | | | underlying memory, and will automatically release it on destruction. Use this to tidy up the orc::IndirectStubsInfo class. llvm-svn: 251731
* [Orc] Teach IndirectStubsManager to manage an expandable pool of stubs, ratherLang Hames2015-10-291-0/+16
| | | | | | | than a pre-allocated slab of stubs. Also add a convenience method for creating a single stub, rather than a whole block a time. llvm-svn: 251658
* [Orc] Add license header to OrcTargetSupport.Lang Hames2015-10-261-1/+9
| | | | llvm-svn: 251274
* [Orc] Add support for emitting indirect stubs directly into the JIT target'sLang Hames2015-10-191-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Orc] Use the 64-bit versions of FXSAVE/FXRSTOR for JIT reentry.Lang Hames2015-04-201-16/+16
| | | | llvm-svn: 235325
* [Orc] Save all the x86-64 GPRs before re-entering the JIT.Lang Hames2015-04-071-6/+13
| | | | | | The re-entry code should work for all calling conventions. llvm-svn: 234298
* [Orc] Tidy up the assembly for the x86-64 resolver block.Lang Hames2015-04-061-44/+45
| | | | llvm-svn: 234138
* [Orc] Refactor JITCompileCallbackManagerBase and CompileOnDemandLayer to supportLang Hames2015-03-251-2/+2
| | | | | | | | target-independent callback management. This is a prerequisite for adding orc-based lazy-jitting to lli. llvm-svn: 233166
* [Orc] Move delta-handling for trampoline sizes into the resolver block.Lang Hames2015-03-241-0/+2
| | | | | | | This is the first step towards adding a target-independent callback handler API. llvm-svn: 233049
* [Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code.Lang Hames2015-02-211-2/+4
| | | | | | NFC. llvm-svn: 230143
* OrcJIT: Appease msc18 not to be confused on executeCompileCallback<OrcX86_64>.NAKAMURA Takumi2015-02-171-2/+3
| | | | llvm-svn: 229494
* Reformat.NAKAMURA Takumi2015-02-171-5/+3
| | | | llvm-svn: 229493
* [Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer.Lang Hames2015-02-171-44/+70
| | | | | | | | | | | | | | This patch replaces most of the Orc indirection utils API with a new class: JITCompileCallbackManager, which creates and manages JIT callbacks. Exposing this functionality directly allows the user to create callbacks that are associated with user supplied compilation actions. For example, you can create a callback to lazyily IR-gen something from an AST. (A kaleidoscope example demonstrating this will be committed shortly). This patch also refactors the CompileOnDemand layer to use the JITCompileCallbackManager API. llvm-svn: 229461
* Re-sort #include lines using my handy dandy ./utils/sort_includes.pyChandler Carruth2015-02-131-1/+0
| | | | | | script. This is in preparation for changes to lots of include lines. llvm-svn: 229088
* [Orc] New JIT APIs.Lang Hames2015-01-231-0/+102
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
OpenPOWER on IntegriCloud