summaryrefslogtreecommitdiffstats
path: root/llvm/examples
Commit message (Collapse)AuthorAgeFilesLines
* [ORC] Fix the LLJITWithObjectCache example to address changes in ce2207abaf9.Lang Hames2020-01-291-4/+4
| | | | (cherry picked from commit 97d000da2e6025600c4709d611e853eb1d5d407c)
* [ORC] Update examples to incorporate changes in ce2207abaf9.Lang Hames2020-01-293-3/+5
| | | | | | | This should fix the builders that were failing due to broken JIT examples after ce2207abaf9. (cherry picked from commit 98e55477558a823b1045b54d5a09681a3c0b819a)
* [examples] Add missing dependency in llvm examplesHiroshi Inoue2020-01-113-0/+3
| | | | To fix build failure with BUILD_SHARED_LIBS=ON
* Fix several issues with compiler extensionsserge-sans-paille2020-01-101-20/+10
| | | | | | | | | | | | | | | | - Update documentation now that the move to monorepo has been made - Do not tie compiler extension testing to LLVM_BUILD_EXAMPLES - No need to specify LLVM libraries for plugins - Add NO_MODULE option to match Polly specific requirements (i.e. building the module *and* linking it statically) - Issue a warning when building the compiler extension with LLVM_BYE_LINK_INTO_TOOLS=ON, as it modifies the behavior of clang, which only makes sense for testing purpose. Still mark llvm/test/Feature/load_extension.ll as XFAIL because of a ManagedStatic dependency that's going to be fixed in a seperate commit. Differential Revision: https://reviews.llvm.org/D72327
* Fix compiler extension example cmake integrationserge-sans-paille2020-01-071-0/+6
| | | | | | | - Do not add it to the Export file - Update install target Differential Revision: https://reviews.llvm.org/D72255
* Re-apply "[Examples] Add IRTransformations directory to examples."Florian Hahn2020-01-046-0/+497
| | | | | | This reverts commit 19fd8925a4afe6efd248688cce06aceff50efe0c. Should include a fix for PR44197.
* Add intrinsics_gen *dependency* on Bye exampleserge-sans-paille2020-01-021-3/+5
|
* Add intrinsics_gen dependency on Bye exampleserge-sans-paille2020-01-021-0/+2
| | | | This fixes build error introduced by commit 24ab9b537e61b3fe5e6a1019492ff6530d82a3ee
* Generalize the pass registration mechanism used by Polly to any third-party toolserge_sans_paille2020-01-023-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | There's quite a lot of references to Polly in the LLVM CMake codebase. However the registration pattern used by Polly could be useful to other external projects: thanks to that mechanism it would be possible to develop LLVM extension without touching the LLVM code base. This patch has two effects: 1. Remove all code specific to Polly in the llvm/clang codebase, replaicing it with a generic mechanism 2. Provide a generic mechanism to register compiler extensions. A compiler extension is similar to a pass plugin, with the notable difference that the compiler extension can be configured to be built dynamically (like plugins) or statically (like regular passes). As a result, people willing to add extra passes to clang/opt can do it using a separate code repo, but still have their pass be linked in clang/opt as built-in passes. Differential Revision: https://reviews.llvm.org/D61446
* [examples] Rename LLJITWithJITLink to LLJITWithCustomObjectLinkingLayer.Lang Hames2019-12-154-17/+15
| | | | | | | | LLJIT now uses JITLink/ObjectLinkingLayer by default where available, so these steps aren't required to use it. The tutorial is still useful though: Clients can use it to test altervative linking layer implementations (e.g. handing off to the system linker) or to test implementations of JITLink that are still under development.
* [examples] Update LLJITWithJITLink example for change in c0143f37dab.Lang Hames2019-12-151-11/+9
|
* [Kaleidoscope][BuildingAJIT] Add a missing std::move.Lang Hames2019-12-151-1/+1
| | | | | This should fix the build failure described in https://github.com/llvm/llvm-project/issues/63.
* [ORC] Remove the automagic Main JITDylib fram ExecutionSession.Lang Hames2019-12-053-22/+26
| | | | | | | | | | | | This patch removes the magic "main" JITDylib from ExecutionEngine. The main JITDylib was created automatically at ExecutionSession construction time, and all subsequently created JITDylibs were added to the main JITDylib's links-against list by default. This saves a couple of lines of boilerplate for simple JIT setups, but this isn't worth introducing magical behavior for. ORCv2 clients should now construct their own main JITDylib using ExecutionSession::createJITDylib and set up its linkages manually using JITDylib::setSearchOrder (or related methods in JITDylib).
* [ORC] Add a runAsMain utility function to ExecutionUtils.Lang Hames2019-12-021-12/+3
| | | | | | | | | | | The runAsMain function takes a pointer to a function with a standard C main signature, int(*)(int, char*[]), and invokes it using the given arguments and program name. The arguments are copied into writable temporary storage as required by the C and C++ specifications, so runAsMain safe to use when calling main functions that modify their arguments in-place. This patch also uses the new runAsMain function to replace hand-rolled versions in lli, llvm-jitlink, and the SpeculativeJIT example.
* Revert "[Examples] Add IRTransformations directory to examples."Florian Hahn2019-12-016-497/+0
| | | | | | | | | This breaks LLVMExports.cmake in some build configurations. PR44197 This reverts commits ceb72d07b004af9c428c4a3c73a98ea97d49a713 7d0b1d77b3d4d47df477519fd1bf099b3df6f899.
* [ORC] Add a utility to support dumping JIT'd objects to disk for debugging.Lang Hames2019-11-143-0/+83
| | | | | | | | | Adds a DumpObjects utility that can be used to dump JIT'd objects to disk. Instances of DebugObjects may be used by ObjectTransformLayer as no-op transforms. This patch also adds an ObjectTransformLayer to LLJIT and an example of how to use this utility to dump JIT'd objects in LLJIT.
* Move CodeGenFileType enum to Support/CodeGen.hReid Kleckner2019-11-131-1/+1
| | | | | | | Avoids the need to include TargetMachine.h from various places just for an enum. Various other enums live here, such as the optimization level, TLS model, etc. Data suggests that this change probably doesn't matter, but it seems nice to have anyway.
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* Fix build with shared libraries. NFC.Michael Liao2019-11-121-0/+6
| | | | - Dependent components need linking directly.
* [Examples] Add IRTransformations directory to examples.Florian Hahn2019-11-126-0/+490
| | | | | | | | | | | | | | | | | | | This patch adds a new IRTransformations directory to llvm/examples/. This is intended to serve as a new home for example transformations/analysis code used by various tutorials. If LLVM_BUILD_EXAMPLES is enabled, the ExamplesIRTransforms library is linked into the opt binary and the example passes become available. To start off with, it contains the CFG simplifications used in the IR part of the 'Getting Started With LLVM: Basics' tutorial at the US LLVM Developers Meeting 2019. Reviewers: paquette, jfb, meikeb, lhames, kbarton Reviewed By: paquette Differential Revision: https://reviews.llvm.org/D69416
* Break out OrcError and RPCChris Bieneman2019-10-291-1/+1
| | | | | | | | | | | | | | | | | | | Summary: When createing an ORC remote JIT target the current library split forces the target process to link large portions of LLVM (Core, Execution Engine, JITLink, Object, MC, Passes, RuntimeDyld, Support, Target, and TransformUtils). This occurs because the ORC RPC interfaces rely on the static globals the ORC Error types require, which starts a cycle of pulling in more and more. This patch breaks the ORC RPC Error implementations out into an "OrcError" library which only depends on LLVM Support. It also pulls the ORC RPC headers into their own subdirectory. With this patch code can include the Orc/RPC/*.h headers and will only incur link dependencies on LLVMOrcError and LLVMSupport. Reviewers: lhames Reviewed By: lhames Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68732
* [examples] Add a dependency on ExecutionEngine to LLJITWithObjectCache example.Lang Hames2019-10-211-0/+1
| | | | | | | | | ExecutionEngine.cpp contains the anchor() for the ObjectCache base class, so we need an explicit dependency on it. Patch by Stephen Neuendorffer. Thanks Stephen! llvm-svn: 375461
* [examples] Fix some comments in the LLJITWithJITLink exampleLang Hames2019-10-181-2/+2
| | | | llvm-svn: 375269
* [examples] Add an example of how to use JITLink and small-code-model with LLJIT.Lang Hames2019-10-183-0/+82
| | | | | | | | | | | | | | | | | | | | | JITLink is LLVM's newer jit-linker. It is an alternative to (and hopefully eventually a replacement for) LLVM's older jit-linker, RuntimeDyld. Unlike RuntimeDyld which requries JIT'd code to be complied with the large code model, JITlink can link code compiled with the small code model, which is the native code model for a number of targets (including all supported MachO targets). This example shows how to: -- Create a JITLink InProcessMemoryManager -- Set the code model to small -- Use a JITLink backed ObjectLinkingLayer as the linking layer for LLJIT (rather than the default RTDyldObjectLinkingLayer). Note: This example will only work on platforms supported by JITLink. As of this commit that's MachO/x86-64 and MachO/arm64. llvm-svn: 375266
* [Orc] Roll back ThreadPool to std::functionBenjamin Kramer2019-09-131-1/+3
| | | | | | MSVC doesn't allow move-only types in std::packaged_task. Boo. llvm-svn: 371844
* [Orc] Address the remaining move-capture FIXMEsBenjamin Kramer2019-09-131-3/+1
| | | | | | | This required spreading unique_function a bit more, which I think is a good thing. llvm-svn: 371843
* [ORCv2] - New Speculate Query ImplementationPraveen Velliengiri2019-08-271-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch introduces, SequenceBBQuery - new heuristic to find likely next callable functions it tries to find the blocks with calls in order of execution sequence of Blocks. It still uses BlockFrequencyAnalysis to find high frequency blocks. For a handful of hottest blocks (plan to customize), the algorithm traverse and discovered the caller blocks along the way to Entry Basic Block and Exit Basic Block. It uses Block Hint, to stop traversing the already visited blocks in both direction. It implicitly assumes that once the block is visited during discovering entry or exit nodes, revisiting them again does not add much. It also branch probability info (cached result) to traverse only hot edges (planned to customize) from hot blocks. Without BPI, the algorithm mostly return's all the blocks in the CFG with calls. It also changes the heuristic queries, so they don't maintain states. Hence it is safe to call from multiple threads. It also implements, new instrumentation to avoid jumping into JIT on every call to the function with the help _orc_speculate.decision.block and _orc_speculate.block. "Speculator Registration Mechanism is also changed" - kudos to @lhames Open to review, mostly looking to change implementation of SequeceBBQuery heuristics with good data structure choices. Reviewers: lhames, dblaikie Reviewed By: lhames Subscribers: mgorny, hiraditya, mgrang, llvm-commits, lhames Tags: #speculative_compilation_in_orc, #llvm Differential Revision: https://reviews.llvm.org/D66399 llvm-svn: 370092
* [ORC] Make sure we linker-mangle symbol names in the SpeculationLayer.Lang Hames2019-08-181-1/+1
| | | | | | If mangling is not performed then speculative lookups will fail. llvm-svn: 369219
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-1524-194/+194
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [ORC] Fix SpeculativeJIT example code broken by r368707.Lang Hames2019-08-131-6/+7
| | | | llvm-svn: 368764
* [ORC] Fix BuildingAJIT tutorial code broken by r368707.Lang Hames2019-08-132-2/+2
| | | | llvm-svn: 368740
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-052-2/+2
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Speculative CompilationPraveen Velliengiri2019-08-033-0/+212
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ORC] Remove Speculator Variants for Different Program Representations [ORC] Block Freq Analysis Speculative Compilation with Naive Block Frequency Add Applications to OrcSpeculation ORC v2 with Block Freq Query & Example Deleted BenchMark Programs Signed-off-by: preejackie <praveenvelliengiri@gmail.com> ORCv2 comments resolved [ORCV2] NFC ORCv2 NFC [ORCv2] Speculative compilation - CFGWalkQuery ORCv2 Adapting IRSpeculationLayer to new locking scheme llvm-svn: 367756
* [ORC] Change the locking scheme for ThreadSafeModule.Lang Hames2019-08-021-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ThreadSafeModule/ThreadSafeContext are used to manage lifetimes and locking for LLVMContexts in ORCv2. Prior to this patch contexts were locked as soon as an associated Module was emitted (to be compiled and linked), and were not unlocked until the emit call returned. This could lead to deadlocks if interdependent modules that shared contexts were compiled on different threads: when, during emission of the first module, the dependence was discovered the second module (which would provide the required symbol) could not be emitted as the thread emitting the first module still held the lock. This patch eliminates this possibility by moving to a finer-grained locking scheme. Each client holds the module lock only while they are actively operating on it. To make this finer grained locking simpler/safer to implement this patch removes the explicit lock method, 'getContextLock', from ThreadSafeModule and replaces it with a new method, 'withModuleDo', that implicitly locks the context, calls a user-supplied function object to operate on the Module, then implicitly unlocks the context before returning the result. ThreadSafeModule TSM = getModule(...); size_t NumFunctions = TSM.withModuleDo( [](Module &M) { // <- context locked before entry to lambda. return M.size(); }); Existing ORCv2 layers that operate on ThreadSafeModules are updated to use the new method. This method is used to introduce Module locking into each of the existing layers. llvm-svn: 367686
* [ORC] Add deprecation warnings to ORCv1 layers and utilities.Lang Hames2019-07-174-23/+26
| | | | | | | | | | | | | | | | | Summary: ORCv1 is deprecated. The current aim is to remove it before the LLVM 10.0 release. This patch adds deprecation attributes to the ORCv1 layers and utilities to warn clients of the change. Reviewers: dblaikie, sgraenitz, AlexDenisov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64609 llvm-svn: 366344
* [ORC] Add custom IR compiler configuration to LLJITBuilder to enable obj caches.Lang Hames2019-07-106-0/+170
| | | | | | | | | | LLJITBuilder now has a setCompileFunctionCreator method which can be used to construct a CompileFunction for the LLJIT instance being created. The motivating use-case for this is supporting ObjectCaches, which can now be set up at compile-function construction time. To demonstrate this an example project, LLJITWithObjectCache, is included. llvm-svn: 365671
* Add a HowToUseLLJIT example project.Lang Hames2019-05-223-0/+85
| | | | | | | A very minimal demo of how to use the LLJIT class, along the lines of the old HowToUseJIT example. llvm-svn: 361435
* [JITLink] Update BuildingAJIT tutorials to account for API changes in r358818.Lang Hames2019-04-202-2/+4
| | | | | | | DynamicLibrarySearchGenerator::GetForCurrentProcess now takes a char (the global prefix) rather than a DataLayout reference. llvm-svn: 358820
* [Kaleidoscope] Fix symbol resolver to search in reverse order.Lang Hames2019-02-211-1/+1
| | | | | | | This should allow more recent definitions of functions in the Kaleidoscope REPL to override old ones, as the tutorial text promises. llvm-svn: 354598
* Fix compilation of examples after 13680223b9d8 / r352827James Y Knight2019-02-014-14/+18
| | | | | | Who knew...they're not built by default or as part of the tests. llvm-svn: 352830
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-016-31/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-316-33/+31
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-316-31/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Fix some warnings on MSVCAlexandre Ganea2019-01-271-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D56329 llvm-svn: 352322
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1916-64/+48
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Python compat - print statementSerge Guelton2019-01-035-13/+23
| | | | | | | | | Make sure all print statements are compatible with Python 2 and Python3 using the `from __future__ import print_function` statement. Differential Revision: https://reviews.llvm.org/D56249 llvm-svn: 350307
* Fix build break from r347239Paul Robinson2018-11-191-3/+2
| | | | llvm-svn: 347246
* Add bracket that was lost in rL346727 and has been causing buildbot failures ↵Simon Pilgrim2018-11-131-1/+1
| | | | | | for some time. llvm-svn: 346752
* [BuildingAJIT] Fixing the build by inserting a forgotten paren.George Karpenkov2018-11-131-1/+1
| | | | llvm-svn: 346730
* [BuildingAJIT] Clang-format chapters 1 and 2.Lang Hames2018-11-133-12/+7
| | | | llvm-svn: 346727
OpenPOWER on IntegriCloud