summaryrefslogtreecommitdiffstats
path: root/mlir/lib/ExecutionEngine
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-232-26/+8
| | | | 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
* Drop MemRefUtils from the ExecutionEngineAlex Zinenko2019-10-232-108/+0
| | | | | | | | | | The ExecutionEngine was updated recently to only take the LLVM dialect as input. Memrefs are no longer expected in the signature of the entry point function by the executor so there is no need to allocate and free them. The code in MemRefUtils is therefore dead and furthermore out of sync with the recent evolution of memref type to support strides. Drop it. PiperOrigin-RevId: 276272302
* Fix minor spelling tweaks (NFC)Kazuaki Ishizaki2019-10-201-1/+1
| | | | | | Closes tensorflow/mlir#177 PiperOrigin-RevId: 275692653
* 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-212-208/+130
| | | | | | | | | | 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
* Add TTI pass initialization to pass managers.Diego Caballero2019-08-051-9/+25
| | | | | | | | | Many LLVM transformations benefits from knowing the targets. This enables optimizations, especially in a JIT context when the target is (generally) well-known. Closes tensorflow/mlir#49 PiperOrigin-RevId: 261840617
* 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
* Update style/clang-format (NFC).Jacques Pienaar2019-07-221-1/+0
| | | | | | Update to be consistent & so that future save + clang-format workflows don't introduce extra changes. PiperOrigin-RevId: 259361174
* 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: Rename Function to FuncOp.River Riddle2019-07-101-1/+1
| | | | PiperOrigin-RevId: 257293379
* 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
* NFC: Refactor Function to be value typed.River Riddle2019-07-011-5/+5
| | | | | | Move the data members out of Function and into a new impl storage class 'FunctionStorage'. This allows for Function to become value typed, which will greatly simplify the transition of Function to FuncOp(given that FuncOp is also value typed). PiperOrigin-RevId: 255983022
* Replace checks against numDynamicDims with hasStaticShapeGeoffrey Martin-Noble2019-06-011-1/+1
| | | | | | -- PiperOrigin-RevId: 250782165
* ExecutionEngine: drop PassManager integrationAlex Zinenko2019-05-202-42/+2
| | | | | | | | | | | | | | | 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
* Update to address missing cmake target & qualify make_pair.Jacques Pienaar2019-05-061-1/+1
| | | | | | -- PiperOrigin-RevId: 246355137
* 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
* Add build files and update README.Jacques Pienaar2019-03-301-0/+10
| | | | | | | | | * Add initial version of build files; * Update README with instructions to download and build MLIR from github; -- PiperOrigin-RevId: 241102092
* 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
* Remove global LLVM CLI variables from library codeDimitrios Vytiniotis2019-03-291-69/+17
| | | | | | Plus move parsing code into the MLIR CPU runner binary. PiperOrigin-RevId: 240786709
* Add missing numeric header for std::accumulate.Jacques Pienaar2019-03-291-0/+1
| | | | PiperOrigin-RevId: 240593135
* Continue pushing const out of the core IR types - in this case, remove constChris Lattner2019-03-291-1/+1
| | | | | | from Function. PiperOrigin-RevId: 239638635
* 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
* ExecutionEngine OptUtils: support -On flags in string-based initializationAlex Zinenko2019-03-291-11/+81
| | | | | | | | | | | | | | Original implementation of OutUtils provided two different LLVM IR module transformers to be used with the MLIR ExecutionEngine: OptimizingTransformer parameterized by the optimization levels (similar to -O3 flags) and LLVMPassesTransformer parameterized by the string formatted similarly to command line options of LLVM's "opt" tool without support for -O* flags. Introduce such support by declaring the flags inside the parser and by populating the pass managers similarly to what "opt" does. Remove the additional flags from mlir-cpu-runner as they can now be wrapped into `-llvm-opts` together with other LLVM-related flags. PiperOrigin-RevId: 236107292
* 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
* ExecutionEngine: provide utils for running CLI-configured LLVM passesAlex Zinenko2019-03-291-0/+118
| | | | | | | | | | | | | | | | | | | A recent change introduced a possibility to run LLVM IR transformation during JIT-compilation in the ExecutionEngine. Provide helper functions that construct IR transformers given either clang-style optimization levels or a list passes to run. The latter wraps the LLVM command line option parser to parse strings rather than actual command line arguments. As a result, we can run either of mlir-cpu-runner -O3 input.mlir mlir-cpu-runner -some-mlir-pass -llvm-opts="-llvm-pass -other-llvm-pass" to combine different transformations. The transformer builder functions are provided as a separate library that depends on LLVM pass libraries unlike the main execution engine library. The library can be used for integrating MLIR execution engine into external frameworks. PiperOrigin-RevId: 234173493
* 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
OpenPOWER on IntegriCloud