summaryrefslogtreecommitdiffstats
path: root/llvm/examples
Commit message (Collapse)AuthorAgeFilesLines
* [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
* [BuildingAJIT] Update chapter 2 to use the ORCv2 APIs.Lang Hames2018-11-132-133/+126
| | | | llvm-svn: 346726
* [BuildingAJIT] Update the Ch1 KaleidoscopeJIT class to expose errors to clients.Lang Hames2018-10-182-36/+38
| | | | | | | | Returning the error to clients provides an opportunity to introduce readers to the Expected and Error APIs and makes the tutorial more useful as a starting point for a real JIT class, while only slightly complicating the code. llvm-svn: 344720
* [BuildingAJIT] Update chapter 1 to use the ORCv2 APIs.Lang Hames2018-10-172-125/+116
| | | | llvm-svn: 344667
* [ORC] Rename ORC layers to make the "new" ORC layers the default.Lang Hames2018-10-156-22/+22
| | | | | | | | | | | | | This commit adds a 'Legacy' prefix to old ORC layers and utilities, and removes the '2' suffix from the new ORC layers. If you wish to continue using the old ORC layers you will need to add a 'Legacy' prefix to your classes. If you were already using the new ORC layers you will need to drop the '2' suffix. The legacy layers will remain in-tree until the new layers reach feature parity with them. This will involve adding support for removing code from the new layers, and ensuring that performance is comperable. llvm-svn: 344572
* [ORC] Fix BuildingAJIT tutorial examples that were broken by r343059.Lang Hames2018-09-262-4/+4
| | | | | | | createLocalCompileCallbackManager now returns an Expected value. This commit wraps the call with cantFail to unwrap it. llvm-svn: 343060
* [ORC] Update JITCompileCallbackManager to support multi-threaded code.Lang Hames2018-05-304-76/+76
| | | | | | | | | 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
* Test Commit Access - Removed Whitespace Luke Geeson2018-05-291-3/+3
| | | | llvm-svn: 333406
* Unbreak kaleidoscope example.Peter Collingbourne2018-05-211-1/+1
| | | | llvm-svn: 332908
* [ORC] Rewrite the VSO symbol table yet again. Update related utilities.Lang Hames2018-05-166-0/+6
| | | | | | | | | | | | | | | | | | | VSOs now track dependencies for materializing symbols. Each symbol must have its dependencies registered with the VSO prior to finalization. Usually this will involve registering the dependencies returned in AsynchronousSymbolQuery::ResolutionResults for queries made while linking the symbols being materialized. Queries against symbols are notified that a symbol is ready once it and all of its transitive dependencies are finalized, allowing compilation work to be broken up and moved between threads without queries returning until their symbols fully safe to access / execute. Related utilities (VSO, MaterializationUnit, MaterializationResponsibility) are updated to support dependence tracking and more explicitly track responsibility for symbols from the point of definition until they are finalized. llvm-svn: 332541
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-297-8/+8
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* Fix build breaks in examples due to moving stuff from Scalar.h to InstCombine.hDavid Blaikie2018-04-244-3/+7
| | | | llvm-svn: 330670
* InstCombine: Fix layering by not including Scalar.h in InstCombineDavid Blaikie2018-04-244-5/+9
| | | | | | | | (notionally Scalar.h is part of libLLVMScalarOpts, so it shouldn't be included by InstCombine which doesn't/shouldn't need to depend on ScalarOpts) llvm-svn: 330669
* [ORC] Create a new SymbolStringPool by default in ExecutionSession constructor.Lang Hames2018-04-026-17/+6
| | | | | | This makes the common case of constructing an ExecutionSession tidier. llvm-svn: 329013
* Transforms: Introduce Transforms/Utils.h rather than spreading the ↵David Blaikie2018-03-281-2/+3
| | | | | | | | | declarations amongst Scalar.h and IPO.h Fixes layering - Transforms/Utils shouldn't depend on including a Scalar or IPO header, because Scalar and IPO depend on Utils. llvm-svn: 328717
* [ORC] Re-apply r327566 with a fix for test-global-ctors.ll.Lang Hames2018-03-154-12/+12
| | | | | | Also clang-formats the patch, which I should have done the first time around. llvm-svn: 327594
* Revert "[ORC] Switch from shared_ptr to unique_ptr for addModule methods."Reid Kleckner2018-03-144-12/+12
| | | | | | | | | | | | | This reverts commit r327566, it breaks test/ExecutionEngine/OrcMCJIT/test-global-ctors.ll. The test doesn't crash with a stack trace, unfortunately. It merely returns 1 as the exit code. ASan didn't produce a report, and I reproduced this on my Linux machine and Windows box. llvm-svn: 327576
* [ORC] Switch from shared_ptr to unique_ptr for addModule methods.Lang Hames2018-03-144-12/+12
| | | | | | | Layer implementations typically mutate module state, and this is better reflected by having layers own the Module they are operating on. llvm-svn: 327566
* [ORC] Consolidate RTDyldObjectLinkingLayer GetMemMgr and GetResolver into aLang Hames2018-02-146-29/+31
| | | | | | | | | unified GetResources callback. Having a single 'GetResources' callback will simplify adding new resources in the future. llvm-svn: 325180
* Update examples for API change. NFC.Rafael Espindola2018-02-142-2/+2
| | | | llvm-svn: 325157
* [ORC] Remove Layer handles from the layer concept.Lang Hames2018-02-096-39/+39
| | | | | | | | | Handles were returned by addModule and used as keys for removeModule, findSymbolIn, and emitAndFinalize. Their job is now subsumed by VModuleKeys, which simplify resource management by providing a consistent handle across all layers. llvm-svn: 324700
* Add OrcJIT dependency for Kaleidoscope Chapter 9.Lang Hames2018-02-061-0/+1
| | | | | | | This should fix the error at http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/10421 llvm-svn: 324413
* [ORC] Start migrating ORC layers to use the new ORC Core.h APIs.Lang Hames2018-02-0612-155/+170
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In particular this patch switches RTDyldObjectLinkingLayer to use orc::SymbolResolver and threads the requried changse (ExecutionSession references and VModuleKeys) through the existing layer APIs. The purpose of the new resolver interface is to improve query performance and better support parallelism, both in JIT'd code and within the compiler itself. The most visibile change is switch of the <Layer>::addModule signatures from: Expected<Handle> addModule(std::shared_ptr<ModuleType> Mod, std::shared_ptr<JITSymbolResolver> Resolver) to: Expected<Handle> addModule(VModuleKey K, std::shared_ptr<ModuleType> Mod); Typical usage of addModule will now look like: auto K = ES.allocateVModuleKey(); Resolvers[K] = createSymbolResolver(...); Layer.addModule(K, std::move(Mod)); See the BuildingAJIT tutorial code for example usage. llvm-svn: 324405
* PR35705: Fix Chapter 9 example code for API changes to DIBuilderDavid Blaikie2017-12-202-2/+4
| | | | llvm-svn: 321214
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 llvm-svn: 319840
OpenPOWER on IntegriCloud