Commit Graph

14 Commits

Author SHA1 Message Date
Lang Hames 3f88a9ea2c [Orc] Teach IndirectStubsManager to manage an expandable pool of stubs, rather
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
2015-10-29 22:04:22 +00:00
Lang Hames 4df7ba7a16 [Orc] Add license header to OrcTargetSupport.
llvm-svn: 251274
2015-10-26 06:40:28 +00:00
Lang Hames 98c2ac13d3 [Orc] Add support for emitting indirect stubs directly into the JIT target's
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
2015-10-19 17:43:51 +00:00
Lang Hames 67e6e04a1e [Orc] Use the 64-bit versions of FXSAVE/FXRSTOR for JIT reentry.
llvm-svn: 235325
2015-04-20 18:25:44 +00:00
Lang Hames ed96cb7fc6 [Orc] Save all the x86-64 GPRs before re-entering the JIT.
The re-entry code should work for all calling conventions.

llvm-svn: 234298
2015-04-07 06:12:21 +00:00
Lang Hames e51ab6e200 [Orc] Tidy up the assembly for the x86-64 resolver block.
llvm-svn: 234138
2015-04-06 03:01:29 +00:00
Lang Hames 8389b55237 [Orc] Refactor JITCompileCallbackManagerBase and CompileOnDemandLayer to support
target-independent callback management.

This is a prerequisite for adding orc-based lazy-jitting to lli.

llvm-svn: 233166
2015-03-25 02:45:50 +00:00
Lang Hames cd118e7632 [Orc] Move delta-handling for trampoline sizes into the resolver block.
This is the first step towards adding a target-independent callback
handler API.

llvm-svn: 233049
2015-03-24 04:27:02 +00:00
Lang Hames e738061c49 [Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code.
NFC.

llvm-svn: 230143
2015-02-21 20:44:36 +00:00
NAKAMURA Takumi cd5a3673c3 OrcJIT: Appease msc18 not to be confused on executeCompileCallback<OrcX86_64>.
llvm-svn: 229494
2015-02-17 12:53:16 +00:00
NAKAMURA Takumi 3e087357ce Reformat.
llvm-svn: 229493
2015-02-17 12:53:05 +00:00
Lang Hames 2754714fb9 [Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer.
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
2015-02-17 01:18:38 +00:00
Chandler Carruth 71f308adb7 Re-sort #include lines using my handy dandy ./utils/sort_includes.py
script. This is in preparation for changes to lots of include lines.

llvm-svn: 229088
2015-02-13 09:09:03 +00:00
Lang Hames 93de2a12a3 [Orc] New JIT APIs.
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
2015-01-23 21:25:00 +00:00