summaryrefslogtreecommitdiffstats
path: root/llvm/lib/ExecutionEngine/Orc/IndirectionUtils.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix few typos in comments (write access test commit)Stefan Granitz2018-07-121-2/+2
| | | | llvm-svn: 336887
* [ORC] Add LLJIT and LLLazyJIT, and replace OrcLazyJIT in LLI with LLLazyJIT.Lang Hames2018-06-261-2/+0
| | | | | | | | | | | | | | | | | | | LLJIT is a prefabricated ORC based JIT class that is meant to be the go-to replacement for MCJIT. Unlike OrcMCJITReplacement (which will continue to be supported) it is not API or bug-for-bug compatible, but targets the same use cases: Simple, non-lazy compilation and execution of LLVM IR. LLLazyJIT extends LLJIT with support for function-at-a-time lazy compilation, similar to what was provided by LLVM's original (now long deprecated) JIT APIs. This commit also contains some simple utility classes (CtorDtorRunner2, LocalCXXRuntimeOverrides2, JITTargetMachineBuilder) to support LLJIT and LLLazyJIT. Both of these classes are works in progress. Feedback from JIT clients is very welcome! llvm-svn: 335670
* [ORC] Fix an ambiguous make_unique call.Lang Hames2018-05-301-2/+2
| | | | llvm-svn: 333492
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-301-5/+90
| | | | | | | | | Previously JITCompileCallbackManager only supported single threaded code. This patch embeds a VSO (see include/llvm/ExecutionEngine/Orc/Core.h) in the callback manager. The VSO ensures that the compile callback is only executed once and that the resulting address cached for use by subsequent re-entries. llvm-svn: 333490
* [ORC] Fix ORC on platforms without indirection support.Lang Hames2018-03-281-1/+5
| | | | | | | | | | Previously this crashed because a nullptr (returned by createLocalIndirectStubsManagerBuilder() on platforms without indirection support) functor was unconditionally invoked. Patch by Andres Freund. Thanks Andres! llvm-svn: 328687
* [ORC] Add case statements for AArch64 to the local stub and callback managerLang Hames2017-08-151-0/+13
| | | | | | | | creation functions. This should allow lli to lazily execute code using OrcLazyJIT on AArch64. llvm-svn: 310938
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* [ORC] Clone module flags metadata into the globals module in theLang Hames2016-09-041-0/+9
| | | | | | | | CompileOnDemandLayer. Also contains a tweak to the orc-lazy jit in LLI to enable the test case. llvm-svn: 280632
* [ExecutionEngine][MCJIT][Orc] Replace RuntimeDyld::SymbolInfo with JITSymbol.Lang Hames2016-08-011-2/+2
| | | | | | | | | | | | | | | | 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
* IR: Introduce local_unnamed_addr attribute.Peter Collingbourne2016-06-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Apply most suggestions of clang-tidy's performance-unnecessary-value-paramBenjamin Kramer2016-06-081-2/+3
| | | | | | | Avoids unnecessary copies. All changes audited & pass tests with asan. No functional change intended. llvm-svn: 272190
* [Orc] Merge some common code for creating CompileCallbackManagers andLang Hames2016-05-261-0/+49
| | | | | | IndirectStubsManagers. llvm-svn: 270874
* [NFC] Header cleanupMehdi Amini2016-04-181-1/+0
| | | | | | | | | | | | | | 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
* GlobalValue: use getValueType() instead of getType()->getPointerElementType().Manuel Jacob2016-01-161-2/+2
| | | | | | | | | | | | Reviewers: mjacob Subscribers: jholewinski, arsenm, dsanders, dblaikie Patch by Eduard Burtescu. Differential Revision: http://reviews.llvm.org/D16260 llvm-svn: 257999
* [Orc] Rename IndirectStubsManagerBase to IndirectStubsManager.Lang Hames2015-12-061-1/+1
| | | | | | 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
* Refactor: Simplify boolean conditional return statements in ↵Alexander Kornienko2015-11-051-3/+1
| | | | | | | | | | lib/llvm/ExecutionEngine/Orc Patch by Richard Thomson! Differential revision: http://reviews.llvm.org/D9973 llvm-svn: 252212
* [Orc] Add support for emitting indirect stubs directly into the JIT target'sLang Hames2015-10-191-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* OrcJIT: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-10-131-1/+1
| | | | llvm-svn: 250192
* [Orc] Teach the CompileOnDemand layer to clone aliases.Lang Hames2015-10-061-0/+14
| | | | | | | | 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
* [Orc] Fix a bug in the CompileOnDemand layer where stub decls were not clonedLang Hames2015-06-121-2/+0
| | | | | | | | | | | 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
* [Orc] Reapply r236465 with fixes for the MSVC bots.Lang Hames2015-05-051-71/+87
| | | | llvm-svn: 236506
* [Orc] Revert r236465 - It broke the Windows bots.Lang Hames2015-05-041-87/+71
| | | | | | | Looks like the usual missing explicit move-constructor issue with MSVC. I should have a fix shortly. llvm-svn: 236472
* [Orc] Refactor the compile-on-demand layer to make module partitioning lazy,Lang Hames2015-05-041-71/+87
| | | | | | | | | | | | | | | 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
* [Orc] Make the makeStub function propagate argument attributes onto the call toLang Hames2015-04-201-0/+1
| | | | | | | | | | | 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
* [Orc] During module partitioning, rename anonymous and asm-private globals.Lang Hames2015-04-121-2/+40
| | | | | | | If they're not (re)named, these globals will fail to resolve when the partitioned modules are linked. llvm-svn: 234707
* [Orc] Tidy up IndirectionUtils API a little, add some comments. NFC.Lang Hames2015-04-111-6/+15
| | | | llvm-svn: 234669
* [Orc] Fix local-linkage handling in the CompileOnDemand layer.Lang Hames2015-04-021-2/+2
| | | | llvm-svn: 233895
* Add missing includes. make_unique proliferated everywhere.Benjamin Kramer2015-03-011-0/+1
| | | | llvm-svn: 230909
* [Orc] Remove redundant using directive.Lang Hames2015-02-221-2/+0
| | | | llvm-svn: 230154
* [Orc] Add header comment to IndirectionUtils.cpp.Lang Hames2015-02-221-0/+9
| | | | llvm-svn: 230153
* [Orc] Move Orc code into a namespace (llvm::orc), update Kaleidoscope code.Lang Hames2015-02-211-1/+3
| | | | | | NFC. llvm-svn: 230143
* [Orc] Update the Orc indirection utils and refactor the CompileOnDemand layer.Lang Hames2015-02-171-124/+76
| | | | | | | | | | | | | | 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/+1
| | | | | | script. This is in preparation for changes to lots of include lines. llvm-svn: 229088
* [Orc] New JIT APIs.Lang Hames2015-01-231-0/+157
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