maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/mlir/tools/mlir-opt/mlir-opt.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

220 lines
8.1 KiB
C++
Raw Normal View History

Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
//===- mlir-opt.cpp - MLIR Optimizer Driver -------------------------------===//
//
Mass update the MLIR license header to mention "Part of the LLVM project" This is an artifact from merging MLIR into LLVM, the file headers are now aligned with the rest of the project.
2020-01-26 11:58:30 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
Adjust License.txt file to use the LLVM license PiperOrigin-RevId: 286906740
2019-12-24 01:35:36 +08:00
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
//
Adjust License.txt file to use the LLVM license PiperOrigin-RevId: 286906740
2019-12-24 01:35:36 +08:00
//===----------------------------------------------------------------------===//
Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
//
Split out mlir-opt main into separate file. Enable reusing the real mlir-opt main from unit tests and in case where additional initialization needs to happen before main is invoked (e.g., when using different command line flag libraries). PiperOrigin-RevId: 254764575
2019-06-24 23:41:52 +08:00
// Main entry function for mlir-opt for when built as standalone binary.
Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
//
//===----------------------------------------------------------------------===//
[mlir][IR] Manually register command line options for MLIRContext and AsmPrinter Summary: This revision makes the registration of command line options for these two files manual with `registerMLIRContextCLOptions` and `registerAsmPrinterCLOptions` methods. This removes the last remaining static constructors within lib/. Differential Revision: https://reviews.llvm.org/D77960
2020-04-12 14:11:51 +08:00
#include "mlir/IR/AsmState.h"
[MLIR] add show-dialects option for mlir-opt Display the list of dialects known to mlir-opt. This is useful for ensuring that linkage has happened correctly, for instance. Differential Revision: https://reviews.llvm.org/D74865
2020-02-19 06:56:45 +08:00
#include "mlir/IR/Dialect.h"
#include "mlir/IR/MLIRContext.h"
[mlir][IR] Manually register command line options for MLIRContext and AsmPrinter Summary: This revision makes the registration of command line options for these two files manual with `registerMLIRContextCLOptions` and `registerAsmPrinterCLOptions` methods. This removes the last remaining static constructors within lib/. Differential Revision: https://reviews.llvm.org/D77960
2020-04-12 14:11:51 +08:00
#include "mlir/InitAllDialects.h"
#include "mlir/InitAllPasses.h"
Add support for registering pass pipelines to the PassRegistry. This is done 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
2019-02-28 06:45:36 +08:00
#include "mlir/Pass/Pass.h"
Port all of the existing passes over to the new pass manager infrastructure. This is largely NFC. PiperOrigin-RevId: 235952357
2019-02-28 02:59:29 +08:00
#include "mlir/Pass/PassManager.h"
Extract openInputFile() into Support/FileUtilities Multiple binaries have the needs to open input files. Use this function to de-duplicate the code. Also changed openOutputFile() to return errors using std::string since it is a library call and accessing I/O in library call is not friendly. PiperOrigin-RevId: 228878221
2019-01-11 23:22:57 +08:00
#include "mlir/Support/FileUtilities.h"
Split out mlir-opt main into separate file. Enable reusing the real mlir-opt main from unit tests and in case where additional initialization needs to happen before main is invoked (e.g., when using different command line flag libraries). PiperOrigin-RevId: 254764575
2019-06-24 23:41:52 +08:00
#include "mlir/Support/MlirOptMain.h"
Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
#include "llvm/Support/CommandLine.h"
#include "llvm/Support/InitLLVM.h"
Expand check-parser-errors to match multiple errrors per line. * check-parser-errors can match multiple errors per line; * Add offset notation to expected-error; PiperOrigin-RevId: 203625348
2018-07-08 10:12:22 +08:00
#include "llvm/Support/SourceMgr.h"
Continue sketching out basic infrastructure, including an input and output filename, and printing of trivial stuff. There is no parser yet, so the input file is ignored. PiperOrigin-RevId: 201596916
2018-06-22 06:22:42 +08:00
#include "llvm/Support/ToolOutputFile.h"
Affine expression analysis and simplification. Outside of IR/ - simplify a MutableAffineMap by flattening the affine expressions - add a simplify affine expression pass that uses this analysis - update the FlatAffineConstraints API (to be used in the next CL) In IR: - add isMultipleOf and getKnownGCD for AffineExpr, and make the in-IR simplication of simplifyMod simpler and more powerful. - rename the AffineExpr visitor methods to distinguish b/w visiting and walking, and to simplify API names based on context. The next CL will use some of these for the loop unrolling/unroll-jam to make the detection for the need of cleanup loop powerful/non-trivial. A future CL will finally move this simplification to FlatAffineConstraints to make it more powerful. For eg., currently, even if a mod expr appearing in a part of the expression tree can't be simplified, the whole thing won't be simplified. PiperOrigin-RevId: 211012256
2018-08-31 08:35:15 +08:00
Continue sketching out basic infrastructure, including an input and output filename, and printing of trivial stuff. There is no parser yet, so the input file is ignored. PiperOrigin-RevId: 201596916
2018-06-22 06:22:42 +08:00
using namespace llvm;
Split out mlir-opt main into separate file. Enable reusing the real mlir-opt main from unit tests and in case where additional initialization needs to happen before main is invoked (e.g., when using different command line flag libraries). PiperOrigin-RevId: 254764575
2019-06-24 23:41:52 +08:00
using namespace mlir;
Continue sketching out basic infrastructure, including an input and output filename, and printing of trivial stuff. There is no parser yet, so the input file is ignored. PiperOrigin-RevId: 201596916
2018-06-22 06:22:42 +08:00
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
// Defined in the test directory, no public header.
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
namespace mlir {
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerConvertToTargetEnvPass();
void registerPassManagerTestPass();
[mlir][spirv] Change the return type for {Min|Max}VersionBase For synthesizing an op's implementation of the generated interface from {Min|Max}Version, we need to define an `initializer` and `mergeAction`. The `initializer` specifies the initial version, and `mergeAction` specifies how version specifications from different parts of the op should be merged to generate a final version requirements. Previously we use the specified version enum as the type for both the initializer and thus the final return type. This means we need to perform `static_cast` over some hopefully not used number (`~0u`) as the initializer. This is quite opaque and sort of not guaranteed to work. Also, there are ops that have an enum attribute where some values declare version requirements (e.g., enumerant `B` requires v1.1+) but some not (e.g., enumerant `A` requires nothing). Then a concrete op instance with `A` will still declare it implements the version interface (because interface implementation is static for an op) but actually theirs no requirements for version. So this commit changes to use an more explicit `llvm::Optional` to wrap around the returned version enum. This should make it more clear. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D108312
2021-11-25 06:28:58 +08:00
void registerPrintSpirvAvailabilityPass();
[mlir] Add a shape function library op Op with mapping from ops to corresponding shape functions for those op in the library and mechanism to associate shape functions to functions. The mapping of operand to shape function is kept separate from the shape functions themselves as the operation is associated to the shape function and not vice versa, and one could have a common library of shape functions that can be used in different contexts. Use fully qualified names and require a name for shape fn lib ops for now and an explicit print/parse (based around the generated one & GPU module op ones). This commit reverts d9da4c3e73720badfcac5c0dc63c0285bb690770. Fixes missing headers (don't know how that was working locally). Differential Revision: https://reviews.llvm.org/D91672
2020-11-30 03:15:30 +08:00
void registerShapeFunctionTestPasses();
[mlir][SideEffects] Define a set of interfaces and traits for defining side effects This revision introduces the infrastructure for defining side-effects and attaching them to operations. This infrastructure allows for defining different types of side effects, that don't interact with each other, but use the same internal mechanisms. At the base of this is an interface that allows operations to specify the different effect instances that are exhibited by a specific operation instance. An effect instance is comprised of the following: * Effect: The specific effect being applied. For memory related effects this may be reading from memory, storing to memory, etc. * Value: A specific value, either operand/result/region argument, the effect pertains to. * Resource: This is a global entity that represents the domain within which the effect is being applied. MLIR serves many different abstractions, which cover many different domains. Simple effects are may have very different context, for example writing to an in-memory buffer vs a database. This revision defines uses this infrastructure to define a set of initial MemoryEffects. The are effects that generally correspond to memory of some kind; Allocate, Free, Read, Write. This set of memory effects will be used in follow revisions to generalize various parts of the compiler, and make others more powerful(e.g. DCE). This infrastructure was originally proposed here: https://groups.google.com/a/tensorflow.org/g/mlir/c/v2mNl4vFCUM Differential Revision: https://reviews.llvm.org/D74439
2020-03-07 05:53:16 +08:00
void registerSideEffectTestPasses();
[mlir][Analysis] Allow Slice Analysis to work with linalg::LinalgOp Differential Revision: https://reviews.llvm.org/D87307
2020-09-11 07:47:29 +08:00
void registerSliceAnalysisTestPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerSymbolTestPasses();
[mlir] Add MemRef filter to affine data copy optimization This patch extends affine data copy optimization utility with an optional memref filter argument. When the memref filter is used, data copy optimization will only generate copies for such a memref. Note: this patch is just porting the memref filter feature from Uday's 'hop' branch: https://github.com/bondhugula/llvm-project/tree/hop. Reviewed By: bondhugula Differential Revision: https://reviews.llvm.org/D74342
2020-02-15 05:41:01 +08:00
void registerTestAffineDataCopyPass();
[MLIR] Introduce utility to hoist affine if/else conditions This revision introduces a utility to unswitch affine.for/parallel loops by hoisting affine.if operations past surrounding affine.for/parallel. The hoisting works for both perfect/imperfect nests and in the presence of else blocks. The hoisting is currently to as outermost a level as possible. Uses a test pass to test the utility. Add convenience method Operation::getParentWithTrait<Trait>. Depends on D77487. Differential Revision: https://reviews.llvm.org/D77870
2020-04-10 19:42:49 +08:00
void registerTestAffineLoopUnswitchingPass();
[mlir] First-party modeling of LLVM types The current modeling of LLVM IR types in MLIR is based on the LLVMType class that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to LLVM itself. This model makes thread-safe type manipulation hard and is being progressively replaced with a cleaner MLIR model that replicates the type system. Introduce a set of classes reflecting the LLVM IR type system in MLIR instead of wrapping the existing types. These are currently introduced as separate classes without affecting the dialect flow, and are exercised through a test dialect. Once feature parity is reached, the old implementation will be gradually substituted with the new one. Depends On D84171 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D84339
2020-07-29 20:58:09 +08:00
void registerTestAllReduceLoweringPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
void registerTestFunc();
void registerTestGpuMemoryPromotionPass();
void registerTestLoopPermutationPass();
void registerTestMatchers();
Implement recursive support into OperationEquivalence::isEquivalentTo() This allows to use OperationEquivalence to track structural comparison for equality between two operations. Differential Revision: https://reviews.llvm.org/D106422
2021-07-29 13:01:04 +08:00
void registerTestOperationEqualPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
void registerTestPrintDefUsePass();
void registerTestPrintNestingPass();
void registerTestReducer();
void registerTestSpirvEntryPointABIPass();
[MLIR][SPIRV] Add rewrite pattern to convert select+cmp into GLSL clamp. Adds rewrite patterns to convert select+cmp instructions into clamp instructions whenever possible. Support is added to convert: - FOrdLessThan, FOrdLessThanEqual to GLSLFClampOp. - SLessThan, SLessThanEqual to GLSLSClampOp. - ULessThan, ULessThanEqual to GLSLUClampOp. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D93618
2020-12-23 22:32:31 +08:00
void registerTestSpirvGLSLCanonicalizationPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
void registerTestSpirvModuleCombinerPass();
void registerTestTraitsPass();
Remove TOSA test passes from non test registration. * Wires them in the same way that peer-dialect test passes are registered. * Fixes the build for -DLLVM_INCLUDE_TESTS=OFF. Differential Revision: https://reviews.llvm.org/D91022
2020-11-08 10:32:35 +08:00
void registerTosaTestQuantUtilAPIPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
void registerVectorizerTestPass();
namespace test {
void registerConvertCallOpPass();
void registerInliner();
void registerMemRefBoundCheck();
void registerPatternsTestPass();
void registerSimpleParametricTilingPass();
void registerTestAffineLoopParametricTilingPass();
[mlir] Add initial support for an alias analysis framework in MLIR This revision adds a new `AliasAnalysis` class that represents the main alias analysis interface in MLIR. The purpose of this class is not to hold the aliasing logic itself, but to provide an interface into various different alias analysis implementations. As it evolves this should allow for users to plug in specialized alias analysis implementations for their own needs, and have them immediately usable by other analyses and transformations. This revision also adds an initial simple generic alias, LocalAliasAnalysis, that provides support for performing stateless local alias queries between values. This class is similar in scope to LLVM's BasicAA. Differential Revision: https://reviews.llvm.org/D92343
2021-02-10 06:11:00 +08:00
void registerTestAliasAnalysisPass();
[mlir] Refactor ElementsAttr into an AttrInterface This revision refactors ElementsAttr into an Attribute Interface. This enables a common interface with which to interact with element attributes, without needing to modify the builtin dialect. It also removes a majority (if not all?) of the need for the current OpaqueElementsAttr, which was originally intended as a way to opaquely represent data that was not representable by the other builtin constructs. The new ElementsAttr interface not only allows for users to natively represent their data in the way that best suits them, it also allows for efficient opaque access and iteration of the underlying data. Attributes using the ElementsAttr interface can directly expose support for interacting with the held elements using any C++ data type they claim to support. For example, DenseIntOrFpElementsAttr supports iteration using various native C++ integer/float data types, as well as APInt/APFloat, and more. ElementsAttr instances that refer to DenseIntOrFpElementsAttr can use all of these data types for iteration: ```c++ DenseIntOrFpElementsAttr intElementsAttr = ...; ElementsAttr attr = intElementsAttr; for (uint64_t value : attr.getValues<uint64_t>()) ...; for (APInt value : attr.getValues<APInt>()) ...; for (IntegerAttr value : attr.getValues<IntegerAttr>()) ...; ``` ElementsAttr also supports failable range/iterator access, allowing for selective code paths depending on data type support: ```c++ ElementsAttr attr = ...; if (auto range = attr.tryGetValues<uint64_t>()) { for (uint64_t value : *range) ...; } ``` Differential Revision: https://reviews.llvm.org/D109190
2021-09-21 09:40:45 +08:00
void registerTestBuiltinAttributeInterfaces();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestCallGraphPass();
[mlir][linalg][bufferize] Add FuncOp bufferization pass This passes bufferizes FuncOp bodies, but not FuncOp boundaries. Differential Revision: https://reviews.llvm.org/D114671
2021-12-07 19:07:13 +08:00
void registerTestComprehensiveFunctionBufferize();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestConstantFold();
[mlir] Conv ops vectorization pass In this commit a new way of convolution ops lowering is introduced. The conv op vectorization pass lowers linalg convolution ops into vector contractions. This lowering is possible when conv op is first tiled by 1 along specific dimensions which transforms it into dot product between input and kernel subview memory buffers. This pass converts such conv op into vector contraction and does all necessary vector transfers that make it work. Differential Revision: https://reviews.llvm.org/D86619
2020-09-08 16:31:52 +08:00
void registerTestConvVectorization();
[mlir] Change test-gpu-to-cubin to derive from SerializeToBlobPass Clean-up after D98279, remove one call to createConvertGPUKernelToBlobPass(). Depends On D98203 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D98360
2021-03-11 00:52:58 +08:00
void registerTestGpuSerializeToCubinPass();
[mlir] Remove mlir-rocm-runner This change combines for ROCm what was done for CUDA in D97463, D98203, D98360, and D98396. I did not try to compile SerializeToHsaco.cpp or test mlir/test/Integration/GPU/ROCM because I don't have an AMD card. I fixed the things that had obvious bit-rot though. Reviewed By: whchung Differential Revision: https://reviews.llvm.org/D98447
2021-03-19 15:22:50 +08:00
void registerTestGpuSerializeToHsacoPass();
[mlir] Introduce data layout modeling subsystem Data layout information allows to answer questions about the size and alignment properties of a type. It enables, among others, the generation of various linear memory addressing schemes for containers of abstract types and deeper reasoning about vectors. This introduces the subsystem for modeling data layouts in MLIR. The data layout subsystem is designed to scale to MLIR's open type and operation system. At the top level, it consists of attribute interfaces that can be implemented by concrete data layout specifications; type interfaces that should be implemented by types subject to data layout; operation interfaces that must be implemented by operations that can serve as data layout scopes (e.g., modules); and dialect interfaces for data layout properties unrelated to specific types. Built-in types are handled specially to decrease the overall query cost. A concrete default implementation of these interfaces is provided in the new Target dialect. Defaults for built-in types that match the current behavior are also provided. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D97067
2021-03-11 21:33:44 +08:00
void registerTestDataLayoutQuery();
[mlir] Add DecomposeCallGraphTypes pass. This replaces the old type decomposition logic that was previously mixed into bufferization, and makes it easily accessible. This also deletes TestFinalizingBufferize, because after we remove the type decomposition, it doesn't do anything that is not already provided by func-bufferize. Differential Revision: https://reviews.llvm.org/D90899
2020-11-06 11:35:15 +08:00
void registerTestDecomposeCallGraphTypes();
[mlir] Add support to SourceMgrDiagnosticHandler for filtering FileLineColLocs This revision adds support for passing a functor to SourceMgrDiagnosticHandler for filtering out FileLineColLocs when emitting a diagnostic. More specifically, this can be useful in situations where there may be large CallSiteLocs with locations that aren't necessarily important/useful for users. For now the filtering support is limited to FileLineColLocs, but conceptually we could allow filtering for all locations types if a need arises in the future. Differential Revision: https://reviews.llvm.org/D103649
2021-06-19 04:30:16 +08:00
void registerTestDiagnosticsPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
void registerTestDominancePass();
Implement a new kind of Pass: dynamic pass pipeline Instead of performing a transformation, such pass yields a new pass pipeline to run on the currently visited operation. This feature can be used for example to implement a sub-pipeline that would run only on an operation with specific attributes. Another example would be to compute a cost model and dynamic schedule a pipeline based on the result of this analysis. Discussion: https://llvm.discourse.group/t/rfc-dynamic-pass-pipeline/1637 Recommit after fixing an ASAN issue: the callback lambda needs to be allocated to a temporary to have its lifetime extended to the end of the current block instead of just the current call expression. Reviewed By: silvas Differential Revision: https://reviews.llvm.org/D86392
2020-09-22 08:51:27 +08:00
void registerTestDynamicPipelinePass();
[mlir] Add support for lowering tanh to LLVMIR. Summary: Fixed build of D81618 Add a pattern for expanding tanh op into exp form. A `tanh` is expanded into: 1) 1-exp^{-2x} / 1+exp^{-2x}, if x => 0 2) exp^{2x}-1 / exp^{2x}+1 , if x < 0. Differential Revision: https://reviews.llvm.org/D82040
2020-06-16 01:26:32 +08:00
void registerTestExpandTanhPass();
Add a pattern to combine composed subview ops Differential Revision: https://reviews.llvm.org/D99229
2021-04-02 01:55:50 +08:00
void registerTestComposeSubView();
[mlir] First-party modeling of LLVM types The current modeling of LLVM IR types in MLIR is based on the LLVMType class that wraps a raw `llvm::Type *` and delegates uniquing, printing and parsing to LLVM itself. This model makes thread-safe type manipulation hard and is being progressively replaced with a cleaner MLIR model that replicates the type system. Introduce a set of classes reflecting the LLVM IR type system in MLIR instead of wrapping the existing types. These are currently introduced as separate classes without affecting the dialect flow, and are exercised through a test dialect. Once feature parity is reached, the old implementation will be gradually substituted with the new one. Depends On D84171 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D84339
2020-07-29 20:58:09 +08:00
void registerTestGpuParallelLoopMappingPass();
[mlir] Add 'Skip' result to Operation visitor This patch is a follow-up on D97217. It adds a new 'Skip' result to the Operation visitor so that a callback can stop the ongoing visit of an operation/block/region and continue visiting the next one without fully interrupting the walk. Skipping is needed to be able to erase an operation/block in pre-order and do not continue visiting the internals of that operation/block. Related to the skipping mechanism, the patch also introduces the following changes: * Added new TestIRVisitors pass with basic testing for the IR visitors. * Fixed missing early increment ranges in visitor implementation. * Updated documentation of walk methods to include erasure information and walk order information. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D97820
2021-03-06 05:47:36 +08:00
void registerTestIRVisitorsPass();
[mlir] Refactor InterfaceGen to support generating interfaces for Attributes and Types. This revision adds support to ODS for generating interfaces for attributes and types, in addition to operations. These interfaces can be specified using `AttrInterface` and `TypeInterface` in place of `OpInterface`. All of the features of `OpInterface` are supported except for the `verify` method, which does not have a matching representation in the Attribute/Type world. Generating these interface can be done using `gen-(attr|type)-interface-(defs|decls|docs)`. Differential Revision: https://reviews.llvm.org/D81884
2020-07-01 06:42:52 +08:00
void registerTestInterfaces();
[mlir][Linalg] Make a Linalg CodegenStrategy available. This revision adds a programmable codegen strategy from linalg based on staged rewrite patterns. Testing is exercised on a simple linalg.matmul op. Differential Revision: https://reviews.llvm.org/D89374
2020-10-14 17:02:47 +08:00
void registerTestLinalgCodegenStrategy();
[mlir]Linalg] Allow controlling fusion of linalg.generic -> linalg.tensor_expand_shape. Differential Revision: https://reviews.llvm.org/D108565
2021-08-24 07:27:15 +08:00
void registerTestLinalgControlFuseByExpansion();
[mlir] Add a pass to distribute linalg::TiledLoopOp. Differential Revision: https://reviews.llvm.org/D103194
2021-05-27 02:22:49 +08:00
void registerTestLinalgDistribution();
[mlir][Linalg] Add callbacks to fusion of elementwise operations to control fusion. Right now Elementwise operations fusion in Linalg fuses everything it can. This can run up against resource limits of the target hardware without some checks. This patch adds a callback function that clients can use to implement a cost function. When two elementwise operations are deemed structurally fusable, the callback can be used to control if the fusion applies. Differential Revision: https://reviews.llvm.org/D99820
2021-04-06 06:44:07 +08:00
void registerTestLinalgElementwiseFusion();
[mlir][linalg] Add pattern to push reshape after elementwise operation This help expose more fusion opportunities. Differential Revision: https://reviews.llvm.org/D100685
2021-04-17 04:38:15 +08:00
void registerTestPushExpandingReshape();
[mlir][Linalg] Add pattern to tile and fuse Linalg operations on buffers. The pattern is structured similar to other patterns like LinalgTilingPattern. The fusion patterns takes options that allows you to fuse with producers of multiple operands at once. - The pattern fuses only at the level that is known to be legal, i.e if a reduction loop in the consumer is tiled, then fusion should happen "before" this loop. Some refactoring of the fusion code is needed to fuse only where it is legal. - Since the fusion on buffers uses the LinalgDependenceGraph that is not mutable in place the fusion pattern keeps the original operations in the IR, but are tagged with a marker that can be later used to find the original operations. This change also fixes an issue with tiling and distribution/interchange where if the tile size of a loop were 0 it wasnt account for in these. Differential Revision: https://reviews.llvm.org/D88435
2020-10-01 05:55:59 +08:00
void registerTestLinalgFusionTransforms();
[mlir][Linalg] Enable TileAndFusePattern to work with tensors. Differential Revision: https://reviews.llvm.org/D94531
2021-01-29 02:51:01 +08:00
void registerTestLinalgTensorFusionTransforms();
[mlir] Add support for fusion into TiledLoopOp. Differential Revision: https://reviews.llvm.org/D102722
2021-05-22 00:13:09 +08:00
void registerTestLinalgTiledLoopFusionTransforms();
[mlir][Linalg] Make Linalg fusion a test pass Linalg "tile-and-fuse" is currently exposed as a Linalg pass "-linalg-fusion" but only the mechanics of the transformation are currently relevant. Instead turn it into a "-test-linalg-greedy-fusion" pass which performs canonicalizations to enable more fusions to compose. This allows dropping the OperationFolder which is not meant to be used with the pattern rewrite infrastructure. Differential Revision: https://reviews.llvm.org/D90394
2020-10-29 22:02:56 +08:00
void registerTestLinalgGreedyFusion();
[mlir][Linalg] Add a hoistViewAllocOps helper function This revision adds a helper function to hoist alloc/dealloc pairs and alloca op out of immediately enclosing scf::ForOp if both conditions are true: 1. all operands are defined outside the loop. 2. all uses are ViewLikeOp or DeallocOp. This is now considered Linalg-specific and will be generalized on a per-need basis. Differential Revision: https://reviews.llvm.org/D81152
2020-06-05 06:55:26 +08:00
void registerTestLinalgHoisting();
[mlir][Linalg] Fuse sequence of Linalg operation (on buffers) Enhance the tile+fuse logic to allow fusing a sequence of operations. Make sure the value used to obtain tile shape is a SubViewOp/SubTensorOp. Current logic used to get the bounds of loop depends on the use of `getOrCreateRange` method on `SubViewOp` and `SubTensorOp`. Make sure that the value/dim used to compute the range is from such ops. This fix is a reasonable WAR, but a btter fix would be to make `getOrCreateRange` method be a method of `ViewInterface`. Differential Revision: https://reviews.llvm.org/D90991
2020-11-24 02:07:34 +08:00
void registerTestLinalgTileAndFuseSequencePass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestLinalgTransforms();
void registerTestLivenessPass();
void registerTestLoopFusion();
void registerTestLoopMappingPass();
[MLIR][LoopOps] Adds the loop unroll transformation for loop::ForOp. Summary: Adds the loop unroll transformation for loop::ForOp. Adds support for promoting the body of single-iteration loop::ForOps into its containing block. Adds check tests for loop::ForOps with dynamic and static lower/upper bounds and step. Care was taken to share code (where possible) with the AffineForOp unroll transformation to ease maintenance and potential future transition to a LoopLike construct on which loop transformations for different loop types can implemented. Reviewers: ftynse, nicolasvasilache Reviewed By: ftynse Subscribers: bondhugula, mgorny, zzheng, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, grosul1, frgossen, Kayjukh, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79184
2020-05-06 01:29:09 +08:00
void registerTestLoopUnrollingPass();
[mlir] Create a generic reduction detection utility This patch introduces a generic reduction detection utility that works across different dialecs. It is mostly a generalization of the reduction detection algorithm in Affine. The reduction detection logic in Affine, Linalg and SCFToOpenMP have been replaced with this new generic utility. The utility takes some basic components of the potential reduction and returns: 1) the reduced value, and 2) a list with the combiner operations. The logic to match reductions involving multiple combiner operations disabled until we can properly test it. Reviewed By: ftynse, bondhugula, nicolasvasilache, pifon2a Differential Revision: https://reviews.llvm.org/D110303
2021-09-23 01:11:45 +08:00
void registerTestMatchReductionPass();
[mlir] Math: add algebraic simplification patterns to math transforms Reviewed By: bkramer Differential Revision: https://reviews.llvm.org/D106822
2021-07-28 00:17:31 +08:00
void registerTestMathAlgebraicSimplificationPass();
[mlir] Add math polynomial approximation pass This gives ~30x speedup compared to expanding Tanh into exp operations: ``` name old cpu/op new cpu/op delta BM_mlir_Tanh_f32/10 253ns ± 3% 55ns ± 7% -78.35% (p=0.000 n=44+41) BM_mlir_Tanh_f32/100 2.21µs ± 4% 0.14µs ± 8% -93.85% (p=0.000 n=48+49) BM_mlir_Tanh_f32/1k 22.6µs ± 4% 0.7µs ± 5% -96.68% (p=0.000 n=32+42) BM_mlir_Tanh_f32/10k 225µs ± 5% 7µs ± 6% -96.88% (p=0.000 n=49+55) name old time/op new time/op delta BM_mlir_Tanh_f32/10 259ns ± 1% 56ns ± 2% -78.31% (p=0.000 n=41+39) BM_mlir_Tanh_f32/100 2.27µs ± 1% 0.14µs ± 5% -93.89% (p=0.000 n=46+49) BM_mlir_Tanh_f32/1k 22.9µs ± 1% 0.8µs ± 4% -96.67% (p=0.000 n=30+42) BM_mlir_Tanh_f32/10k 230µs ± 0% 7µs ± 3% -96.88% (p=0.000 n=37+55) ``` This approximations is based on Eigen::generic_fast_tanh function Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D96739
2021-02-19 08:24:56 +08:00
void registerTestMathPolynomialApproximationPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestMemRefDependenceCheck();
void registerTestMemRefStrideCalculation();
[mlir] Add NumberOfExecutions analysis + update RegionBranchOpInterface interface to query number of region invocations Implements RFC discussed in: https://llvm.discourse.group/t/rfc-operationinstancesinterface-or-any-better-name/2158/10 Reviewed By: silvas, ftynse, rriddle Differential Revision: https://reviews.llvm.org/D90922
2020-11-11 17:38:51 +08:00
void registerTestNumberOfBlockExecutionsPass();
void registerTestNumberOfOperationExecutionsPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestOpaqueLoc();
[mlir][PDL] Add support for PDL bytecode and expose PDL support to OwningRewritePatternList PDL patterns are now supported via a new `PDLPatternModule` class. This class contains a ModuleOp with the pdl::PatternOp operations representing the patterns, as well as a collection of registered C++ functions for native constraints/creations/rewrites/etc. that may be invoked via the pdl patterns. Instances of this class are added to an OwningRewritePatternList in the same fashion as C++ RewritePatterns, i.e. via the `insert` method. The PDL bytecode is an in-memory representation of the PDL interpreter dialect that can be efficiently interpreted/executed. The representation of the bytecode boils down to a code array(for opcodes/memory locations/etc) and a memory buffer(for storing attributes/operations/values/any other data necessary). The bytecode operations are effectively a 1-1 mapping to the PDLInterp dialect operations, with a few exceptions in cases where the in-memory representation of the bytecode can be more efficient than the MLIR representation. For example, a generic `AreEqual` bytecode op can be used to represent AreEqualOp, CheckAttributeOp, and CheckTypeOp. The execution of the bytecode is split into two phases: matching and rewriting. When matching, all of the matched patterns are collected to avoid the overhead of re-running parts of the matcher. These matched patterns are then considered alongside the native C++ patterns, which rewrite immediately in-place via `RewritePattern::matchAndRewrite`, for the given root operation. When a PDL pattern is matched and has the highest benefit, it is passed back to the bytecode to execute its rewriter. Differential Revision: https://reviews.llvm.org/D89107
2020-12-02 06:30:18 +08:00
void registerTestPDLByteCodePass();
[mlir] Introduce allowMemrefFunctionResults for the helper operation converters of buffer placement This parameter gives the developers the freedom to choose their desired function signature conversion for preparing their functions for buffer placement. It is introduced for BufferAssignmentFuncOpConverter, and also for BufferAssignmentReturnOpConverter, and BufferAssignmentCallOpConverter to adapt the return and call operations with the selected function signature conversion. If the parameter is set, buffer placement won't also deallocate the returned buffers. Differential Revision: https://reviews.llvm.org/D81137
2020-06-03 00:12:57 +08:00
void registerTestPreparationPassWithAllowedMemrefResults();
[mlir] Support for mutable types Introduce support for mutable storage in the StorageUniquer infrastructure. This makes MLIR have key-value storage instead of just uniqued key storage. A storage instance now contains a unique immutable key and a mutable value, both stored in the arena allocator that belongs to the context. This is a preconditio for supporting recursive types that require delayed initialization, in particular LLVM structure types. The functionality is exercised in the test pass with trivial self-recursive type. So far, recursive types can only be printed in parsed in a closed type system. Removing this restriction is left for future work. Differential Revision: https://reviews.llvm.org/D84171
2020-07-22 19:03:24 +08:00
void registerTestRecursiveTypesPass();
[mlir][SCF] Add utility to clone an scf.ForOp while appending new yield values. This utility factors out the machinery required to add iterArgs and yield values to an scf.ForOp. Differential Revision: https://reviews.llvm.org/D80656
2020-05-29 18:42:35 +08:00
void registerTestSCFUtilsPass();
[mlir] Make topologicalSort iterative and consider op regions When doing topological sort we need to make sure an op is scheduled before any of the ops within its regions. Also change the algorithm to not be recursive in order to prevent potential stack overflow. Differential Revision: https://reviews.llvm.org/D113423
2021-11-10 10:11:33 +08:00
void registerTestSliceAnalysisPass();
[mlir][X86Vector] Add specialized vector.transpose lowering patterns for AVX2 This revision adds an implementation of 2-D vector.transpose for 4x8 and 8x8 for AVX2 and surfaces it to the Linalg level of control. Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D113347
2021-11-10 21:19:41 +08:00
void registerTestVectorLowerings();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
} // namespace test
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
} // namespace mlir
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
namespace test {
void registerTestDialect(DialectRegistry &);
} // namespace test
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
#ifdef MLIR_INCLUDE_TESTS
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
void registerTestPasses() {
registerConvertToTargetEnvPass();
registerPassManagerTestPass();
[mlir][spirv] Change the return type for {Min|Max}VersionBase For synthesizing an op's implementation of the generated interface from {Min|Max}Version, we need to define an `initializer` and `mergeAction`. The `initializer` specifies the initial version, and `mergeAction` specifies how version specifications from different parts of the op should be merged to generate a final version requirements. Previously we use the specified version enum as the type for both the initializer and thus the final return type. This means we need to perform `static_cast` over some hopefully not used number (`~0u`) as the initializer. This is quite opaque and sort of not guaranteed to work. Also, there are ops that have an enum attribute where some values declare version requirements (e.g., enumerant `B` requires v1.1+) but some not (e.g., enumerant `A` requires nothing). Then a concrete op instance with `A` will still declare it implements the version interface (because interface implementation is static for an op) but actually theirs no requirements for version. So this commit changes to use an more explicit `llvm::Optional` to wrap around the returned version enum. This should make it more clear. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D108312
2021-11-25 06:28:58 +08:00
registerPrintSpirvAvailabilityPass();
[mlir] Add a shape function library op Op with mapping from ops to corresponding shape functions for those op in the library and mechanism to associate shape functions to functions. The mapping of operand to shape function is kept separate from the shape functions themselves as the operation is associated to the shape function and not vice versa, and one could have a common library of shape functions that can be used in different contexts. Use fully qualified names and require a name for shape fn lib ops for now and an explicit print/parse (based around the generated one & GPU module op ones). This commit reverts d9da4c3e73720badfcac5c0dc63c0285bb690770. Fixes missing headers (don't know how that was working locally). Differential Revision: https://reviews.llvm.org/D91672
2020-11-30 03:15:30 +08:00
registerShapeFunctionTestPasses();
[mlir][SideEffects] Define a set of interfaces and traits for defining side effects This revision introduces the infrastructure for defining side-effects and attaching them to operations. This infrastructure allows for defining different types of side effects, that don't interact with each other, but use the same internal mechanisms. At the base of this is an interface that allows operations to specify the different effect instances that are exhibited by a specific operation instance. An effect instance is comprised of the following: * Effect: The specific effect being applied. For memory related effects this may be reading from memory, storing to memory, etc. * Value: A specific value, either operand/result/region argument, the effect pertains to. * Resource: This is a global entity that represents the domain within which the effect is being applied. MLIR serves many different abstractions, which cover many different domains. Simple effects are may have very different context, for example writing to an in-memory buffer vs a database. This revision defines uses this infrastructure to define a set of initial MemoryEffects. The are effects that generally correspond to memory of some kind; Allocate, Free, Read, Write. This set of memory effects will be used in follow revisions to generalize various parts of the compiler, and make others more powerful(e.g. DCE). This infrastructure was originally proposed here: https://groups.google.com/a/tensorflow.org/g/mlir/c/v2mNl4vFCUM Differential Revision: https://reviews.llvm.org/D74439
2020-03-07 05:53:16 +08:00
registerSideEffectTestPasses();
[mlir][Analysis] Allow Slice Analysis to work with linalg::LinalgOp Differential Revision: https://reviews.llvm.org/D87307
2020-09-11 07:47:29 +08:00
registerSliceAnalysisTestPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerSymbolTestPasses();
[mlir] Add MemRef filter to affine data copy optimization This patch extends affine data copy optimization utility with an optional memref filter argument. When the memref filter is used, data copy optimization will only generate copies for such a memref. Note: this patch is just porting the memref filter feature from Uday's 'hop' branch: https://github.com/bondhugula/llvm-project/tree/hop. Reviewed By: bondhugula Differential Revision: https://reviews.llvm.org/D74342
2020-02-15 05:41:01 +08:00
registerTestAffineDataCopyPass();
[MLIR] Introduce utility to hoist affine if/else conditions This revision introduces a utility to unswitch affine.for/parallel loops by hoisting affine.if operations past surrounding affine.for/parallel. The hoisting works for both perfect/imperfect nests and in the presence of else blocks. The hoisting is currently to as outermost a level as possible. Uses a test pass to test the utility. Add convenience method Operation::getParentWithTrait<Trait>. Depends on D77487. Differential Revision: https://reviews.llvm.org/D77870
2020-04-10 19:42:49 +08:00
registerTestAffineLoopUnswitchingPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
registerTestAllReduceLoweringPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerTestFunc();
registerTestGpuMemoryPromotionPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
registerTestLoopPermutationPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerTestMatchers();
Implement recursive support into OperationEquivalence::isEquivalentTo() This allows to use OperationEquivalence to track structural comparison for equality between two operations. Differential Revision: https://reviews.llvm.org/D106422
2021-07-29 13:01:04 +08:00
registerTestOperationEqualPass();
Add a doc/tutorial on traversing the IR Reviewed By: stephenneuendorffer Differential Revision: https://reviews.llvm.org/D87221
2020-09-08 08:06:37 +08:00
registerTestPrintDefUsePass();
registerTestPrintNestingPass();
Create TestReducer pass - Create a pass that generates bugs based on trivially defined behavior for the purpose of testing the MLIR Reduce Tool. - Implement the functionality inside the pass to crash mlir-opt in the presence of an operation with the name "crashOp". - Register the pass as a test pass in the mlir-opt tool. Reviewed by: jpienaar Differential Revision: https://reviews.llvm.org/D83422
2020-07-11 08:46:55 +08:00
registerTestReducer();
[mlir][GPUToSPIRV] Add a test pass to set workgroup size for kernel functions. This allows using command line flags to lowere from GPU to SPIR-V. The pass added is only for testing/example purposes. Most uses cases will need more fine-grained control on setting workgroup sizes for kernel functions. Differential Revision: https://reviews.llvm.org/D84619
2020-07-29 02:47:30 +08:00
registerTestSpirvEntryPointABIPass();
[MLIR][SPIRV] Add rewrite pattern to convert select+cmp into GLSL clamp. Adds rewrite patterns to convert select+cmp instructions into clamp instructions whenever possible. Support is added to convert: - FOrdLessThan, FOrdLessThanEqual to GLSLFClampOp. - SLessThan, SLessThanEqual to GLSLSClampOp. - ULessThan, ULessThanEqual to GLSLUClampOp. Reviewed By: mravishankar Differential Revision: https://reviews.llvm.org/D93618
2020-12-23 22:32:31 +08:00
registerTestSpirvGLSLCanonicalizationPass();
[MLIR][SPIRV] Start module combiner. This commit adds a new library that merges/combines a number of spv modules into a combined one. The library has a single entry point: combine(...). To combine a number of MLIR spv modules, we move all the module-level ops from all the input modules into one big combined module. To that end, the combination process can proceed in 2 phases: (1) resolving conflicts between pairs of ops from different modules (2) deduplicate equivalent ops/sub-ops in the merged module. (TODO) This patch implements only the first phase. Reviewed By: antiagainst Differential Revision: https://reviews.llvm.org/D90477
2020-10-31 02:36:19 +08:00
registerTestSpirvModuleCombinerPass();
[MLIR] Add a foldTrait() mechanism to allow traits to define folding and test it with an Involution trait This is the same diff as https://reviews.llvm.org/D88809/ except side effect free check is removed for involution and a FIXME is added until the dependency is resolved for shared builds. The old diff has more details on possible fixes. Reviewed By: rriddle, andyly Differential Revision: https://reviews.llvm.org/D89333
2020-10-14 04:58:19 +08:00
registerTestTraitsPass();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerVectorizerTestPass();
Remove TOSA test passes from non test registration. * Wires them in the same way that peer-dialect test passes are registered. * Fixes the build for -DLLVM_INCLUDE_TESTS=OFF. Differential Revision: https://reviews.llvm.org/D91022
2020-11-08 10:32:35 +08:00
registerTosaTestQuantUtilAPIPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerConvertCallOpPass();
mlir::test::registerInliner();
mlir::test::registerMemRefBoundCheck();
mlir::test::registerPatternsTestPass();
mlir::test::registerSimpleParametricTilingPass();
mlir::test::registerTestAffineLoopParametricTilingPass();
mlir::test::registerTestAliasAnalysisPass();
[mlir] Refactor ElementsAttr into an AttrInterface This revision refactors ElementsAttr into an Attribute Interface. This enables a common interface with which to interact with element attributes, without needing to modify the builtin dialect. It also removes a majority (if not all?) of the need for the current OpaqueElementsAttr, which was originally intended as a way to opaquely represent data that was not representable by the other builtin constructs. The new ElementsAttr interface not only allows for users to natively represent their data in the way that best suits them, it also allows for efficient opaque access and iteration of the underlying data. Attributes using the ElementsAttr interface can directly expose support for interacting with the held elements using any C++ data type they claim to support. For example, DenseIntOrFpElementsAttr supports iteration using various native C++ integer/float data types, as well as APInt/APFloat, and more. ElementsAttr instances that refer to DenseIntOrFpElementsAttr can use all of these data types for iteration: ```c++ DenseIntOrFpElementsAttr intElementsAttr = ...; ElementsAttr attr = intElementsAttr; for (uint64_t value : attr.getValues<uint64_t>()) ...; for (APInt value : attr.getValues<APInt>()) ...; for (IntegerAttr value : attr.getValues<IntegerAttr>()) ...; ``` ElementsAttr also supports failable range/iterator access, allowing for selective code paths depending on data type support: ```c++ ElementsAttr attr = ...; if (auto range = attr.tryGetValues<uint64_t>()) { for (uint64_t value : *range) ...; } ``` Differential Revision: https://reviews.llvm.org/D109190
2021-09-21 09:40:45 +08:00
mlir::test::registerTestBuiltinAttributeInterfaces();
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestCallGraphPass();
mlir::test::registerTestConstantFold();
mlir::test::registerTestDiagnosticsPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
#if MLIR_CUDA_CONVERSIONS_ENABLED
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestGpuSerializeToCubinPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
#endif
#if MLIR_ROCM_CONVERSIONS_ENABLED
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestGpuSerializeToHsacoPass();
[mlir] Move TestDialect and its passes to mlir::test namespace. TestDialect has many operations and they all live in ::mlir namespace. Sometimes it is not clear whether the ops used in the code for the test passes belong to Standard or to Test dialects. Also, with this change it is easier to understand what test passes registered in mlir-opt are actually passes in mlir/test. Differential Revision: https://reviews.llvm.org/D90794
2020-11-05 05:18:26 +08:00
#endif
[mlir][linalg][bufferize] Add FuncOp bufferization pass This passes bufferizes FuncOp bodies, but not FuncOp boundaries. Differential Revision: https://reviews.llvm.org/D114671
2021-12-07 19:07:13 +08:00
mlir::test::registerTestComprehensiveFunctionBufferize();
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestConvVectorization();
mlir::test::registerTestDecomposeCallGraphTypes();
mlir::test::registerTestDataLayoutQuery();
mlir::test::registerTestDominancePass();
mlir::test::registerTestDynamicPipelinePass();
mlir::test::registerTestExpandTanhPass();
mlir::test::registerTestComposeSubView();
mlir::test::registerTestGpuParallelLoopMappingPass();
mlir::test::registerTestIRVisitorsPass();
mlir::test::registerTestInterfaces();
mlir::test::registerTestLinalgCodegenStrategy();
[mlir]Linalg] Allow controlling fusion of linalg.generic -> linalg.tensor_expand_shape. Differential Revision: https://reviews.llvm.org/D108565
2021-08-24 07:27:15 +08:00
mlir::test::registerTestLinalgControlFuseByExpansion();
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestLinalgDistribution();
mlir::test::registerTestLinalgElementwiseFusion();
mlir::test::registerTestPushExpandingReshape();
mlir::test::registerTestLinalgFusionTransforms();
mlir::test::registerTestLinalgTensorFusionTransforms();
mlir::test::registerTestLinalgTiledLoopFusionTransforms();
mlir::test::registerTestLinalgGreedyFusion();
mlir::test::registerTestLinalgHoisting();
mlir::test::registerTestLinalgTileAndFuseSequencePass();
mlir::test::registerTestLinalgTransforms();
mlir::test::registerTestLivenessPass();
mlir::test::registerTestLoopFusion();
mlir::test::registerTestLoopMappingPass();
mlir::test::registerTestLoopUnrollingPass();
[mlir] Create a generic reduction detection utility This patch introduces a generic reduction detection utility that works across different dialecs. It is mostly a generalization of the reduction detection algorithm in Affine. The reduction detection logic in Affine, Linalg and SCFToOpenMP have been replaced with this new generic utility. The utility takes some basic components of the potential reduction and returns: 1) the reduced value, and 2) a list with the combiner operations. The logic to match reductions involving multiple combiner operations disabled until we can properly test it. Reviewed By: ftynse, bondhugula, nicolasvasilache, pifon2a Differential Revision: https://reviews.llvm.org/D110303
2021-09-23 01:11:45 +08:00
mlir::test::registerTestMatchReductionPass();
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
mlir::test::registerTestMathAlgebraicSimplificationPass();
mlir::test::registerTestMathPolynomialApproximationPass();
mlir::test::registerTestMemRefDependenceCheck();
mlir::test::registerTestMemRefStrideCalculation();
mlir::test::registerTestNumberOfBlockExecutionsPass();
mlir::test::registerTestNumberOfOperationExecutionsPass();
mlir::test::registerTestOpaqueLoc();
mlir::test::registerTestPDLByteCodePass();
mlir::test::registerTestRecursiveTypesPass();
mlir::test::registerTestSCFUtilsPass();
[mlir] Make topologicalSort iterative and consider op regions When doing topological sort we need to make sure an op is scheduled before any of the ops within its regions. Also change the algorithm to not be recursive in order to prevent potential stack overflow. Differential Revision: https://reviews.llvm.org/D113423
2021-11-10 10:11:33 +08:00
mlir::test::registerTestSliceAnalysisPass();
[mlir][X86Vector] Add specialized vector.transpose lowering patterns for AVX2 This revision adds an implementation of 2-D vector.transpose for 4x8 and 8x8 for AVX2 and surfaces it to the Linalg level of control. Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D113347
2021-11-10 21:19:41 +08:00
mlir::test::registerTestVectorLowerings();
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
}
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
#endif
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
Add negative parsing tests using mlir-opt. Add parsing tests with errors. Follows direct path of splitting file into test groups (using a marker) and parsing each section individually. The expected errors are checked using FileCheck and parser error does not result in terminating parsing the rest of the file if check-parser-error. This is an interim approach until refactoring lexer/parser. PiperOrigin-RevId: 201867941
2018-06-25 00:10:36 +08:00
int main(int argc, char **argv) {
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerAllPasses();
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
#ifdef MLIR_INCLUDE_TESTS
Remove static registration for dialects, and the "alwayslink" hack for passes In the previous state, we were relying on forcing the linker to include all libraries in the final binary and the global initializer to self-register every piece of the system. This change help moving away from this model, and allow users to compose pieces more freely. The current change is only "fixing" the dialect registration and avoiding relying on "whole link" for the passes. The translation is still relying on the global registry, and some refactoring is needed to make this all more convenient. Differential Revision: https://reviews.llvm.org/D74461
2020-02-12 17:03:40 +08:00
registerTestPasses();
[MLIR] Use `MLIR_INCLUDE_TESTS` to conditionally compile tests. This is equivalent to what is done for other projects (e.g. clang). Differential Revision: https://reviews.llvm.org/D80022
2020-05-19 00:44:26 +08:00
#endif
Separate the Registration from Loading dialects in the Context This changes the behavior of constructing MLIRContext to no longer load globally registered dialects on construction. Instead Dialects are only loaded explicitly on demand: - the Parser is lazily loading Dialects in the context as it encounters them during parsing. This is the only purpose for registering dialects and not load them in the context. - Passes are expected to declare the dialects they will create entity from (Operations, Attributes, or Types), and the PassManager is loading Dialects into the Context when starting a pipeline. This changes simplifies the configuration of the registration: a compiler only need to load the dialect for the IR it will emit, and the optimizer is self-contained and load the required Dialects. For example in the Toy tutorial, the compiler only needs to load the Toy dialect in the Context, all the others (linalg, affine, std, LLVM, ...) are automatically loaded depending on the optimization pipeline enabled. To adjust to this change, stop using the existing dialect registration: the global registry will be removed soon. 1) For passes, you need to override the method: virtual void getDependentDialects(DialectRegistry &registry) const {} and registery on the provided registry any dialect that this pass can produce. Passes defined in TableGen can provide this list in the dependentDialects list field. 2) For dialects, on construction you can register dependent dialects using the provided MLIRContext: `context.getOrLoadDialect<DialectName>()` This is useful if a dialect may canonicalize or have interfaces involving another dialect. 3) For loading IR, dialect that can be in the input file must be explicitly registered with the context. `MlirOptMain()` is taking an explicit registry for this purpose. See how the standalone-opt.cpp example is setup: mlir::DialectRegistry registry; registry.insert<mlir::standalone::StandaloneDialect>(); registry.insert<mlir::StandardOpsDialect>(); Only operations from these two dialects can be in the input file. To include all of the dialects in MLIR Core, you can populate the registry this way: mlir::registerAllDialects(registry); 4) For `mlir-translate` callback, as well as frontend, Dialects can be loaded in the context before emitting the IR: context.getOrLoadDialect<ToyDialect>() Differential Revision: https://reviews.llvm.org/D85622
2020-08-19 04:01:19 +08:00
DialectRegistry registry;
registerAllDialects(registry);
Fix MLIR build with MLIR_INCLUDE_TESTS=OFF error message /usr/bin/ld: CMakeFiles/mlir-opt.dir/mlir-opt.cpp.o: in function `main': mlir-opt.cpp:(.text.startup.main+0xb9): undefined reference to `mlir::registerTestDialect(mlir::DialectRegistry&)' Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D86592
2020-08-27 12:01:23 +08:00
#ifdef MLIR_INCLUDE_TESTS
[MLIR] Move TestDialect to ::test namespace While the changes are extensive, they basically fall into a few categories: 1) Moving the TestDialect itself. 2) Updating C++ code in tablegen to explicitly use ::mlir, since it will be put in a headers that shouldn't expect a 'using'. 3) Updating some generic MLIR Interface definitions to do the same thing. 4) Updating the Tablegen generator in a few places to be explicit about namespaces 5) Doing the same thing for llvm references, since we no longer pick up the definitions from mlir/Support/LLVM.h Differential Revision: https://reviews.llvm.org/D88251
2020-09-25 02:54:46 +08:00
::test::registerTestDialect(registry);
Fix MLIR build with MLIR_INCLUDE_TESTS=OFF error message /usr/bin/ld: CMakeFiles/mlir-opt.dir/mlir-opt.cpp.o: in function `main': mlir-opt.cpp:(.text.startup.main+0xb9): undefined reference to `mlir::registerTestDialect(mlir::DialectRegistry&)' Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D86592
2020-08-27 12:01:23 +08:00
#endif
Add a helper function to convert LogicalResult to int for return from main At present, a lot of code contains main function bodies like "return failed(mlir::MlirOptMain(...);". This is unfortunate for two reasons: a) it uses ADL, which is maybe not what the free "failed" function was designed for; and b) it is a bit awkward to read, requring the reader to both understand the boolean nature of the value and the semantics of main's return value. (And it's also not portable, since 1 is not a portable success value.) The replacement code, `return mlir::AsMainReturnCode(mlir::MlirOptMain(...))` is a bit more self-explanatory. The change applies the new function to a few internal uses of MlirOptMain, too. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D102641
2021-05-19 07:44:25 +08:00
return mlir::asMainReturnCode(
mlir::MlirOptMain(argc, argv, "MLIR modular optimizer driver\n", registry,
/*preloadDialectsInContext=*/false));
Sketch out a new repository for the mlir project (go/mlir). PiperOrigin-RevId: 201540159
2018-06-22 00:49:33 +08:00
}