Commit Graph

32 Commits

Author SHA1 Message Date
Lang Hames 368c4223b8 [lli] Add the ability for OrcLazyJIT to accept multiple input modules.
LLI already supported passing multiple input modules to MCJIT via the
-extra-module option. This patch adds the plumbing to pass these modules to
the OrcLazy JIT too.

This functionality will be used in an upcoming test case for weak symbol
handling.

llvm-svn: 277521
2016-08-02 21:00:40 +00:00
Lang Hames ad4a911fea [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.
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
2016-08-01 20:49:11 +00:00
Lang Hames 656532075b [Orc] Add conversion to/from RuntimeDyld::SymbolInfo for JITSymbol.
This tidies up some code that was manually constructing RuntimeDyld::SymbolInfo
instances from JITSymbols. It will save more mess in the future when
JITSymbol::getAddress is extended to return an Expected<TargetAddress> rather
than just a TargetAddress, since we'll be able to embed the error checking in
the conversion.

llvm-svn: 271350
2016-05-31 23:14:26 +00:00
Lang Hames 105518fe3c [Orc] Merge some common code for creating CompileCallbackManagers and
IndirectStubsManagers.

llvm-svn: 270874
2016-05-26 17:20:35 +00:00
Lang Hames bf9d1aa931 [RuntimeDyld] Call the SymbolResolver::findSymbolInLogicalDylib method when
searching for external symbols, and fall back to the SymbolResolver::findSymbol
method if the former returns null.

This makes RuntimeDyld behave more like a static linker: Symbol definitions
from within the current module's "logical dylib" will be preferred to
external definitions. We can build on this behavior in the future to properly
support weak symbol handling.

Custom symbol resolvers that override the findSymbolInLogicalDylib method may
notice changes due to this patch. Clients who have not overridden this method
should generally be unaffected, however users of the OrcMCJITReplacement class
may notice changes.

llvm-svn: 270716
2016-05-25 16:23:59 +00:00
Lang Hames 829826bf96 [Orc] Enable user-supplied memory managers in the CompileOnDemand layer.
Previously the CompileOnDemand layer was hard-coded to use a new
SectionMemoryManager for each function when it was called.

llvm-svn: 257265
2016-01-09 20:55:18 +00:00
Lang Hames f0f4b4c882 [Orc] Rename JITCompileCallbackManagerBase to JITCompileCallbackManager.
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
2015-12-04 02:15:39 +00:00
Rafael Espindola e63e0188e4 Revert "Revert "[Orc] Directly emit machine code for the x86 resolver block and trampolines.""
This reverts commit r251937.

The test was updated to the new API, bring the API back.

llvm-svn: 251944
2015-11-03 16:40:37 +00:00
Rafael Espindola 2f344637d6 Revert "[Orc] Directly emit machine code for the x86 resolver block and trampolines."
This reverts commit r251933.

It broke the build of examples/Kaleidoscope/Orc/fully_lazy/toy.cpp.

llvm-svn: 251937
2015-11-03 16:25:20 +00:00
Lang Hames a4a227f7e8 [Orc] Directly emit machine code for the x86 resolver block and trampolines.
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
2015-11-03 16:10:18 +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 6df48a97d2 [Orc] Enable user supplied partitioning functors in the CompileOnDemand layer.
Previously the CompileOnDemand layer always created single-function partitions.
In theory this new API allows for more interesting partitions, though this has
not been well tested yet.

llvm-svn: 249623
2015-10-07 21:53:41 +00:00
Mehdi Amini 26d481311a Remove access to the DataLayout in the TargetMachine
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
2015-07-24 16:04:22 +00:00
Mehdi Amini 5d8e569926 Revert "Remove access to the DataLayout in the TargetMachine"
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
2015-07-24 03:36:55 +00:00
Mehdi Amini b4bc424c9a Remove access to the DataLayout in the TargetMachine
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
2015-07-24 01:44:39 +00:00
Rafael Espindola c233f74e6e Simplify the Mangler interface now that DataLayout is mandatory.
We only need to pass in a DataLayout when mangling a raw string, not when
constructing the mangler.

llvm-svn: 240405
2015-06-23 13:59:29 +00:00
Lang Hames 37cc9fadd5 [Orc] Tidy up initialization based on review feedback for r239561 from dblaikie.
NFC.

llvm-svn: 239645
2015-06-12 23:13:06 +00:00
Lang Hames 2e36ddf671 [Orc] Fix a bug in the CompileOnDemand layer where stub decls were not cloned
into partitions. Also, add an option to clone stub definitions (not just decls)
into partitions: these definitions could be inlined in some places to avoid the
overhead of calling via the stub.

Found by inspection - no test case yet, although I plan to add a unit test for
this once the CompileOnDemand layer refactoring settles down.

llvm-svn: 239640
2015-06-12 21:31:15 +00:00
Lang Hames 3f9960a969 [Orc] Remove some unnecesary includes and whitespace that slipped in to r239561.
NFC.

llvm-svn: 239564
2015-06-11 22:12:24 +00:00
Lang Hames 6a14edd914 [Orc] Make partition identification in the CompileOnDemand layer lazy.
This also breaks out the logical dylib symbol resolution logic.

llvm-svn: 239561
2015-06-11 21:45:19 +00:00
Benjamin Kramer f5e2fc474d Replace push_back(Constructor(foo)) with emplace_back(foo) for non-trivial types
If the type isn't trivially moveable emplace can skip a potentially
expensive move. It also saves a couple of characters.


Call sites were found with the ASTMatcher + some semi-automated cleanup.

memberCallExpr(
    argumentCountIs(1), callee(methodDecl(hasName("push_back"))),
    on(hasType(recordDecl(has(namedDecl(hasName("emplace_back")))))),
    hasArgument(0, bindTemporaryExpr(
                       hasType(recordDecl(hasNonTrivialDestructor())),
                       has(constructExpr()))),
    unless(isInTemplateInstantiation()))

No functional change intended.

llvm-svn: 238602
2015-05-29 19:43:39 +00:00
Lang Hames cd68eba3b9 [Orc] Reapply r236465 with fixes for the MSVC bots.
llvm-svn: 236506
2015-05-05 17:37:18 +00:00
Lang Hames ac31a1f141 [Orc] Revert r236465 - It broke the Windows bots.
Looks like the usual missing explicit move-constructor issue with MSVC. I should
have a fix shortly.

llvm-svn: 236472
2015-05-04 23:30:01 +00:00
Lang Hames a68970dfd5 [Orc] Refactor the compile-on-demand layer to make module partitioning lazy,
and avoid cloning unused decls into every partition.

Module partitioning showed up as a source of significant overhead when I
profiled some trivial test cases. Avoiding the overhead of partitionging
for uncalled functions helps to mitigate this.

This change also means that it is no longer necessary to have a
LazyEmittingLayer underneath the CompileOnDemand layer, since the
CompileOnDemandLayer will not extract or emit function bodies until they are
called.

llvm-svn: 236465
2015-05-04 22:03:10 +00:00
Lang Hames 66aa00f904 [Orc] Refactor the CompileOnDemandLayer to make its addModuleSet method
signature match the other layers.

This makes it possible to compose other layers (e.g. IRTransformLayer) on top
of CompileOnDemandLayer.

llvm-svn: 235029
2015-04-15 18:26:24 +00:00
Lang Hames cd3fd83c3a [Orc] Add an Orc layer for applying arbitrary transforms to IR, use it to add
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
2015-04-13 22:12:54 +00:00
Lang Hames b1cd98a18d [Orc] Add support classes for inspecting and running C++ static ctor/dtors, and
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
2015-04-02 04:34:45 +00:00
Lang Hames 5a9808b7ed [Orc] Reflect process symbols into the LLI Orc-lazy JIT.
This makes symbol resolution essentially identical between MCJIT and the LLI
Orc-lazy JIT.

llvm-svn: 233786
2015-04-01 04:42:56 +00:00
Lang Hames 3c9e20de2e [Orc] Separate callback manager selection from callback manager construction for
OrcLazyJIT in lli.

Separating these concerns enables more natural error handling.

llvm-svn: 233579
2015-03-30 18:37:01 +00:00
Lang Hames 633fe146e9 [MCJIT][Orc] Refactor RTDyldMemoryManager, weave RuntimeDyld::SymbolInfo through
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
2015-03-30 03:37:06 +00:00
Lang Hames d57308f20e [Orc] Remove another unnecessary typedef.
llvm-svn: 233184
2015-03-25 12:32:36 +00:00
Lang Hames 9528bbaae0 [Orc][lli] Add a very simple Orc-based lazy JIT to lli.
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
2015-03-25 12:11:48 +00:00