Commit Graph

28 Commits

Author SHA1 Message Date
Lang Hames 38c7927b6f [ORC] Clone module flags metadata into the globals module in the
CompileOnDemandLayer.

Also contains a tweak to the orc-lazy jit in LLI to enable the test case.

llvm-svn: 280632
2016-09-04 17:53:30 +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
Peter Collingbourne 96efdd6107 IR: Introduce local_unnamed_addr attribute.
If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.

This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
  the normal rule that the global must have a unique address can be broken without
  being observable by the program by performing comparisons against the global's
  address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
  its own copy of the global if it requires one, and the copy in each linkage unit
  must be the same)
- It is a constant or a function (which means that the program cannot observe that
  the unique-address rule has been broken by writing to the global)

Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.

See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.

Part of the fix for PR27553.

Differential Revision: http://reviews.llvm.org/D20348

llvm-svn: 272709
2016-06-14 21:01:22 +00:00
Benjamin Kramer c321e53402 Apply most suggestions of clang-tidy's performance-unnecessary-value-param
Avoids unnecessary copies. All changes audited & pass tests with asan.
No functional change intended.

llvm-svn: 272190
2016-06-08 19:09:22 +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
Mehdi Amini b550cb1750 [NFC] Header cleanup
Removed some unused headers, replaced some headers with forward class declarations.

Found using simple scripts like this one:
clear && ack --cpp -l '#include "llvm/ADT/IndexedMap.h"' | xargs grep -L 'IndexedMap[<]' | xargs grep -n --color=auto 'IndexedMap'

Patch by Eugene Kosov <claprix@yandex.ru>

Differential Revision: http://reviews.llvm.org/D19219

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266595
2016-04-18 09:17:29 +00:00
Manuel Jacob 5f6eaac611 GlobalValue: use getValueType() instead of getType()->getPointerElementType().
Reviewers: mjacob

Subscribers: jholewinski, arsenm, dsanders, dblaikie

Patch by Eduard Burtescu.

Differential Revision: http://reviews.llvm.org/D16260

llvm-svn: 257999
2016-01-16 20:30:46 +00:00
Lang Hames ea39de81e4 [Orc] Rename IndirectStubsManagerBase to IndirectStubsManager.
No functional change.

llvm-svn: 254885
2015-12-06 19:44:45 +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
Alexander Kornienko db73c2f54c Refactor: Simplify boolean conditional return statements in lib/llvm/ExecutionEngine/Orc
Patch by Richard Thomson!

Differential revision: http://reviews.llvm.org/D9973

llvm-svn: 252212
2015-11-05 21:18:09 +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
Duncan P. N. Exon Smith 1275bffa96 OrcJIT: Remove implicit ilist iterator conversions, NFC
llvm-svn: 250192
2015-10-13 18:10:59 +00:00
Lang Hames 44780acd91 [Orc] Teach the CompileOnDemand layer to clone aliases.
This allows modules containing aliases to be lazily jit'd. Previously these
failed with missing symbol errors because the aliases weren't cloned from the
original module.

llvm-svn: 249481
2015-10-06 22:55:05 +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 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 dc4260db2a [Orc] Make the makeStub function propagate argument attributes onto the call to
the function body.

This is necessary for correctness when lazily compiling.

Also, flesh out the Orc unit test infrastructure slightly, and add a unit test
for this.

llvm-svn: 235347
2015-04-20 20:41:45 +00:00
Lang Hames c6de458f7c [Orc] During module partitioning, rename anonymous and asm-private globals.
If they're not (re)named, these globals will fail to resolve when the
partitioned modules are linked.

llvm-svn: 234707
2015-04-12 20:05:51 +00:00
Lang Hames eb9bdb5d16 [Orc] Tidy up IndirectionUtils API a little, add some comments. NFC.
llvm-svn: 234669
2015-04-11 00:23:49 +00:00
Lang Hames 2f50744fe7 [Orc] Fix local-linkage handling in the CompileOnDemand layer.
llvm-svn: 233895
2015-04-02 05:28:10 +00:00
Benjamin Kramer 0a446fd56c Add missing includes. make_unique proliferated everywhere.
llvm-svn: 230909
2015-03-01 21:28:53 +00:00
Lang Hames d1c2082c39 [Orc] Remove redundant using directive.
llvm-svn: 230154
2015-02-22 01:48:23 +00:00
Lang Hames 53ccf88893 [Orc] Add header comment to IndirectionUtils.cpp.
llvm-svn: 230153
2015-02-22 01:45:31 +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
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