summaryrefslogtreecommitdiffstats
path: root/mlir/lib/ExecutionEngine/ExecutionEngine.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [mlir][orc] unbreak MLIR ExecutionEngine after ORC changesAlex Zinenko2020-01-301-3/+3
| | | | | | | | | | Changes to ORC in ce2207abaf9a925b35f15ef92aaff6b301ba6d22 changed the APIs in IRCompileLayer, now requiring the custom compiler to be wrapped in IRCompileLayer::IRCompiler. Even though MLIR relies on Orc CompileUtils, the type is still visible in several places in the code. Adapt those to the new API. (cherry picked from commit 7984b47401f7f36475619abf2ff02de3b5ff0481)
* Make helper functions static or move them into anonymous namespaces. NFC.Benjamin Kramer2020-01-141-1/+1
|
* Adjust License.txt file to use the LLVM licenseMehdi Amini2019-12-231-13/+4
| | | | PiperOrigin-RevId: 286906740
* NFC: Cleanup non-conforming usages of namespaces.River Riddle2019-12-181-5/+2
| | | | | | | * Fixes use of anonymous namespace for static methods. * Uses explicit qualifiers(mlir::) instead of wrapping the definition with the namespace. PiperOrigin-RevId: 286222654
* NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared ↵River Riddle2019-12-181-10/+9
| | | | | | | | in `mlir` namespace. Aside from being cleaner, this also makes the codebase more consistent. PiperOrigin-RevId: 286206974
* Fix MLIR Build after LLVM upstream JIT changes (getMainJITDylib removed)Mehdi Amini2019-12-051-1/+4
| | | | | | The getMainJITDylib() method was removed in 4fc68b9b7f, replace it by creating a JITDylib on the fly. PiperOrigin-RevId: 283948595
* Print reason why dynamic library could not be loaded during execution.Christian Sigg2019-10-281-1/+2
| | | | PiperOrigin-RevId: 277037138
* Don't leak TargetMachine in ExecutionEngine::setupTargetTripleMLIR Team2019-09-101-2/+2
| | | | PiperOrigin-RevId: 268361054
* Set mlir-cpu-runner JIT codegen opt level correctlyUday Bondhugula2019-09-071-0/+3
| | | | | | | | | | | | - the JIT codegen was being run at the default -O0 level; instead, propagate the opt level from the cmd line. Signed-off-by: Uday Bondhugula <uday@polymagelabs.com> Closes tensorflow/mlir#123 COPYBARA_INTEGRATE_REVIEW=https://github.com/tensorflow/mlir/pull/123 from bondhugula:jit-runner 3b055e47f94c9a48bf487f6400787478738cda02 PiperOrigin-RevId: 267778586
* Wrap debug dump in LLVM_DEBUGMehdi Amini2019-09-071-4/+7
| | | | PiperOrigin-RevId: 267774506
* Use transform function on llvm::Module in the ExecutionEngineNicolas Vasilache2019-09-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The refactoring of ExecutionEngine dropped the usage of the irTransform function used to pass -O3 and other options to LLVM. As a consequence, the proper optimizations do not kick in in LLMV-land. This CL makes use of the transform function and allows producing avx512 instructions, on an internal example, when using: `mlir-cpu-runner -dump-object-file=1 -object-filename=foo.o` combined with `objdump -D foo.o`. Assembly produced resembles: ``` 2b2e: 62 72 7d 48 18 04 0e vbroadcastss (%rsi,%rcx,1),%zmm8 2b35: 62 71 7c 48 28 ce vmovaps %zmm6,%zmm9 2b3b: 62 72 3d 48 a8 c9 vfmadd213ps %zmm1,%zmm8,%zmm9 2b41: 62 f1 7c 48 28 cf vmovaps %zmm7,%zmm1 2b47: 62 f2 3d 48 a8 c8 vfmadd213ps %zmm0,%zmm8,%zmm1 2b4d: 62 f2 7d 48 18 44 0e vbroadcastss 0x4(%rsi,%rcx,1),%zmm0 2b54: 01 2b55: 62 71 7c 48 28 c6 vmovaps %zmm6,%zmm8 2b5b: 62 72 7d 48 a8 c3 vfmadd213ps %zmm3,%zmm0,%zmm8 2b61: 62 f1 7c 48 28 df vmovaps %zmm7,%zmm3 2b67: 62 f2 7d 48 a8 da vfmadd213ps %zmm2,%zmm0,%zmm3 2b6d: 62 f2 7d 48 18 44 0e vbroadcastss 0x8(%rsi,%rcx,1),%zmm0 2b74: 02 2b75: 62 f2 7d 48 a8 f5 vfmadd213ps %zmm5,%zmm0,%zmm6 2b7b: 62 f2 7d 48 a8 fc vfmadd213ps %zmm4,%zmm0,%zmm7 ``` etc. Fixes tensorflow/mlir#120 PiperOrigin-RevId: 267281097
* Add mechanism to dump JIT-compiled objects to filesJacques Pienaar2019-08-301-9/+32
| | | | | | | | | | | This commit introduces the bits to be able to dump JIT-compile objects to external files by passing an object cache to OrcJit. The new functionality is tested in mlir-cpu-runner under the flag `dump-object-file`. Closes tensorflow/mlir#95 PiperOrigin-RevId: 266439265
* Reduce reliance on custom grown Jit implementation - NFCNicolas Vasilache2019-08-211-207/+118
| | | | | | | | | | This CL makes use of the standard LLVM LLJIT and removes the need for a custom JIT implementation within MLIR. To achieve this, one needs to clone (i.e. serde) the produced llvm::Module into a new LLVMContext. This is currently necessary because the llvm::LLVMContext is owned by the LLVMDialect, somewhat deep in the call hierarchy. In the future we should remove the reliance of serding the llvm::Module by allowing the injection of an LLVMContext from the top-level. Unfortunately this will require deeper API changes and impact multiple places. It is therefore left for future work. PiperOrigin-RevId: 264737459
* Change from llvm::make_unique to std::make_uniqueJacques Pienaar2019-08-171-6/+6
| | | | | | | | Switch to C++14 standard method as llvm::make_unique has been removed ( https://reviews.llvm.org/D66259). Also mark some targets as c++14 to ease next integrates. PiperOrigin-RevId: 263953918
* ExecutionEngine: fix after upstream LLVM ORC updateAlex Zinenko2019-08-151-5/+6
| | | | | | | | LLVM r368707 updated the APIs in llvm::orc::DynamicLibrarySearchGenerator to use unique_ptr for holding the instance of the generator. Update our uses of DynamicLibrarySearchGenerator in the ExecutionEngine to reflect that. PiperOrigin-RevId: 263539855
* Fix ExecutionEngine post-update in upstream LLVMAlex Zinenko2019-08-041-1/+3
| | | | | | | | | LLVM r367686 changed the locking scheme to avoid potential deadlocks and the related llvm::orc::ThreadSafeModule APIs ExecutionEngine was relying upon, breaking the MLIR build. Update our use of ThreadSafeModule to unbreak the build. PiperOrigin-RevId: 261566571
* NFC: Rename Module to ModuleOp.River Riddle2019-07-101-1/+1
| | | | | | Module is a legacy name that only exists as a typedef of ModuleOp. PiperOrigin-RevId: 257427248
* NFC: Refactor Module to be value typed.River Riddle2019-07-021-2/+2
| | | | | | As with Functions, Module will soon become an operation, which are value-typed. This eases the transition from Module to ModuleOp. A new class, OwningModuleRef is provided to allow for owning a reference to a Module, and will auto-delete the held module on destruction. PiperOrigin-RevId: 256196193
* ExecutionEngine: drop PassManager integrationAlex Zinenko2019-05-201-41/+1
| | | | | | | | | | | | | | | Originally, ExecutionEngine was created before MLIR had a proper pass management infrastructure or an LLVM IR dialect (using the LLVM target directly). It has been running a bunch of lowering passes to convert the input IR from Standard+Affine dialects to LLVM IR and, later, to the LLVM IR dialect. This is no longer necessary and is even undesirable for compilation flows that perform their own conversion to the LLVM IR dialect. Drop this integration and make ExecutionEngine accept only the LLVM IR dialect. Users of the ExecutionEngine can call the relevant passes themselves. -- PiperOrigin-RevId: 249004676
* Cleanup linalg integration testNicolas Vasilache2019-05-201-10/+43
| | | | | | | | | | This CL performs post-commit cleanups. It adds the ability to specify which shared libraries to load dynamically in ExecutionEngine. The linalg integration test is updated to use a shared library. Additional minor cleanups related to LLVM lowering of Linalg are also included. -- PiperOrigin-RevId: 248346589
* Pipe Linalg to a cblas call via mlir-cpu-runnerNicolas Vasilache2019-05-201-6/+51
| | | | | | | | | This CL extends the execution engine to allow the additional resolution of symbols names that have been registered explicitly. This allows linking static library symbols that have not been explicitly exported with the -rdynamic linking flag (which is deemed too intrusive). -- PiperOrigin-RevId: 247969504
* ExecutionEngine: update to reflect LLVM API changesAlex Zinenko2019-04-231-1/+1
| | | | | | | | | | | LLVM Orc JIT changed the API for DynamicLibrarySearchGenerator:: GetForCurrentProcess to only take one value of the DataLayout that it actually uses instead of the whole data layout. Update MLIR ExecutionEngine call to this function accordingly. -- PiperOrigin-RevId: 244820235
* Expose `setupTargetTriple` as a public static method on ExecutionEngineMehdi Amini2019-04-111-1/+1
| | | | | | | | | | This allows client to be able to reuse the same logic to setup a module for the ExecutionEngine without instanciating one. One use case is running the optimization pipeline but not JIT-ing. -- PiperOrigin-RevId: 242614380
* ExecutionEngine: allow for running MLIR passes during JIT-compilationAlex Zinenko2019-04-071-7/+11
| | | | | | | | | | | | | | | | | The existing implementation of the ExecutionEngine unconditionally runs a list of "default" MLIR passes on the module upon creation. These passes include, among others, dialect conversions from affine to standard and from standard to LLVM IR dialects. In some cases, these conversions might have been performed before ExecutionEngine is created. More advanced use cases may be performing additional transformations that the "default" passes will conflict with. Provide an overload for ExecutionEngine::create that takes a PassManager configured with the passes to run on the module. If it is not provided, do not run any passes. The engine will not be created if the input module, after the pass manager, has any other dialect than the LLVM IR dialect. -- PiperOrigin-RevId: 242127393
* Deduplicate constant folding logic in ConstantFold and ↵Lei Zhang2019-04-051-1/+1
| | | | | | | | | | | | | | | | | | | | | GreedyPatternRewriteDriver There are two places containing constant folding logic right now: the ConstantFold pass and the GreedyPatternRewriteDriver. The logic was not shared and started to drift apart. We were testing constant folding logic using the ConstantFold pass, but lagged behind the GreedyPatternRewriteDriver, where we really want the constant folding to happen. This CL pulled the logic into utility functions and classes for sharing between these two places. A new ConstantFoldHelper class is created to help constant fold and de-duplication. Also, renamed the ConstantFold pass to TestConstantFold to make it clear that it is intended for testing purpose. -- PiperOrigin-RevId: 241971681
* Address some errors from g++Jacques Pienaar2019-03-291-3/+3
| | | | | | | | | These fail with: could not convert ‘module’ from ‘llvm::orc::ThreadSafeModule’ to ‘llvm::Expected<llvm::orc::ThreadSafeModule>’ PiperOrigin-RevId: 240892583
* Continue pushing const out of the IR types - removing the notion of a 'constChris Lattner2019-03-291-1/+1
| | | | | | Module'. NFC. PiperOrigin-RevId: 239532885
* Move `createConvertToLLVMIRPass()` to its own header matching the target ↵Mehdi Amini2019-03-291-0/+1
| | | | | | library clients need to link PiperOrigin-RevId: 237723197
* Update the PassManager infrastructure to return Status instead of bool.River Riddle2019-03-291-1/+1
| | | | PiperOrigin-RevId: 237261205
* Remove PassResult and have the runOnFunction/runOnModule functions return ↵River Riddle2019-03-291-1/+1
| | | | | | void instead. To signal a pass failure, passes should now invoke the 'signalPassFailure' method. This provides the equivalent functionality when needed, but isn't an intrusive part of the API like PassResult. PiperOrigin-RevId: 236202029
* Add support for registering pass pipelines to the PassRegistry. This is done ↵River Riddle2019-03-291-9/+10
| | | | | | | | | | | | | | | | | | | by providing a static registration facility PassPipelineRegistration that works similarly to PassRegistration except for it also takes a function that will add necessary passes to a provided PassManager. void pipelineBuilder(PassManager &pm) { pm.addPass(new MyPass()); pm.addPass(new MyOtherPass()); } static PassPipelineRegistration Unused("unused", "Unused pass", pipelineBuilder); This is also useful for registering specializations of existing passes: Pass *createFooPass10() { return new FooPass(10); } static PassPipelineRegistration Unused("unused", "Unused pass", createFooPass10); PiperOrigin-RevId: 235996282
* Port all of the existing passes over to the new pass manager infrastructure. ↵River Riddle2019-03-291-27/+15
| | | | | | This is largely NFC. PiperOrigin-RevId: 235952357
* NFC: Refactor the files related to passes.River Riddle2019-03-291-1/+1
| | | | | | | * PassRegistry is split into its own source file. * Pass related files are moved to a new library 'Pass'. PiperOrigin-RevId: 234705771
* Reimplement LLVM IR translation to use the MLIR LLVM IR dialectAlex Zinenko2019-03-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Original implementation of the translation from MLIR to LLVM IR operated on the Standard+BuiltIn dialect, with a later addition of the SuperVector dialect. This required the translation to be aware of a potetially large number of other dialects as the infrastructure extended. With the recent introduction of the LLVM IR dialect into MLIR, the translation can be switched to only translate the LLVM IR dialect, and the translation of the operations becomes largely mechanical. The reimplementation of the translator follows the lines of the original translator in function and basic block conversion. In particular, block arguments are converted to LLVM IR PHI nodes, which are connected to their sources after all blocks of a function had been converted. Thanks to LLVM IR types being wrapped in the MLIR LLVM dialect type, type conversion is simplified to only convert function types, all other types are simply unwrapped. Individual instructions are constructed using the LLVM IRBuilder, which has a great potential for being table-generated from the LLVM IR dialect operation definitions. The input of the test/Target/llvmir.mlir is updated to use the MLIR LLVM IR dialect. While it is now redundant with the dialect conversion test, the point of the exercise is to guarantee exactly the same LLVM IR is emitted. (Only the name of the allocation function is changed from `__mlir_alloc` to `alloc` in the CHECK lines.) It will be simplified in a follow-up commit. PiperOrigin-RevId: 233842306
* Cleanups in ExecutionEngine.Alex Zinenko2019-03-291-5/+2
| | | | | | | | | | Make sure the module is always passed to the optimization layer. Drop unused default argument for the IR transformation and remove the function that was only used in this default argument. The transformation wrapper constructor already checks for the null function, so the caller can just pass `{}` if they don't want any transformation (no callers currently need this). PiperOrigin-RevId: 233068817
* ExecutionEngine: provide a hook for LLVM IR passesAlex Zinenko2019-03-291-6/+34
| | | | | | | | | | | | | The current ExecutionEngine flow generates the LLVM IR from MLIR and JIT-compiles it as is without any transformation. It thus misses the opportunity to perform optimizations supported by LLVM or collect statistics about the module. Modify the Orc JITter to perform transformations on the LLVM IR. Accept an optional LLVM module transformation function when constructing the ExecutionEngine and use it while JIT-compiling. This prevents MLIR ExecutionEngine from depending on LLVM passes; its clients should depend on the passes they require. PiperOrigin-RevId: 232877060
* Fix use of llvm::Module::getOrInsertFunction after the upstream opaque ↵River Riddle2019-03-291-2/+3
| | | | | | pointer type changes. PiperOrigin-RevId: 232002583
* Add a C API for EDSCs in other languages + pythonNicolas Vasilache2019-03-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL adds support for calling EDSCs from other languages than C++. Following the LLVM convention this CL: 1. declares simple opaque types and a C API in mlir-c/Core.h; 2. defines the implementation directly in lib/EDSC/Types.cpp and lib/EDSC/MLIREmitter.cpp. Unlike LLVM however the nomenclature for these types and API functions is not well-defined, naming suggestions are most welcome. To avoid the need for conversion functions, Types.h and MLIREmitter.h include mlir-c/Core.h and provide constructors and conversion operators between the mlir::edsc type and the corresponding C type. In this first commit, mlir-c/Core.h only contains the types for the C API to allow EDSCs to work from Python. This includes both a minimal set of core MLIR types (mlir_context_t, mlir_type_t, mlir_func_t) as well as the EDSC types (edsc_mlir_emitter_t, edsc_expr_t, edsc_stmt_t, edsc_indexed_t). This can be restructured in the future as concrete needs arise. For now, the API only supports: 1. scalar types; 2. memrefs of scalar types with static or symbolic shapes; 3. functions with input and output of these types. The C API is not complete wrt ownership semantics. This is in large part due to the fact that python bindings are written with Pybind11 which allows very idiomatic C++ bindings. An effort is made to write a large chunk of these bindings using the C API but some C++isms are used where the design benefits from this simplication. A fully isolated C API will make more sense once we also integrate with another language like Swift and have enough use cases to drive the design. Lastly, this CL also fixes a bug in mlir::ExecutionEngine were the order of declaration of llvmContext and the JIT result in an improper order of destructors (which used to crash before the fix). PiperOrigin-RevId: 231290250
* Add a simple arity-agnostic invocation of JIT-compiled functions.Nicolas Vasilache2019-03-291-0/+12
| | | | | | | This is useful to call generic function with unspecified number of arguments e.g. when interfacing with ML frameworks. PiperOrigin-RevId: 230974736
* Use a unique_ptr instead of manual deletion for PIMPL idiom (NFC)Mehdi Amini2019-03-291-5/+3
| | | | PiperOrigin-RevId: 230930254
* Simple CPU runnerAlex Zinenko2019-03-291-0/+299
This implements a simple CPU runner based on LLVM Orc JIT. The base functionality is provided by the ExecutionEngine class that compiles and links the module, and provides an interface for obtaining function pointers to the JIT-compiled MLIR functions and for invoking those functions directly. Since function pointers need to be casted to the correct pointer type, the ExecutionEngine wraps LLVM IR functions obtained from MLIR into a helper function with the common signature `void (void **)` where the single argument is interpreted as a list of pointers to the actual arguments passed to the function, eventually followed by a pointer to the result of the function. Additionally, the ExecutionEngine is set up to resolve library functions to those available in the current process, enabling support for, e.g., simple C library calls. For integration purposes, this also provides a simplistic runtime for memref descriptors as expected by the LLVM IR code produced by MLIR translation. In particular, memrefs are transformed into LLVM structs (can be mapped to C structs) with a pointer to the data, followed by dynamic sizes. This implementation only supports statically-shaped memrefs of type float, but can be extened if necessary. Provide a binary for the runner and a test that exercises it. PiperOrigin-RevId: 230876363
OpenPOWER on IntegriCloud