summaryrefslogtreecommitdiff
path: root/mlir/lib/Conversion/AffineToStandard
AgeCommit message (Collapse)Author
2025-07-23[mlir][NFC] update `Conversion` create APIs (4/n) (#149879)Maksim Levental
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2025-07-04[mlir] Remove unused includes (NFC) (#147101)Kazu Hirata
These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures.
2025-02-17[MLIR][NFC] Retire `let constructor` for passes in Conversion directory ↵lorenzo chelini
(part1) (#127403) `let constructor` is deprecated since the table gen backend emits most of the glue logic to build a pass. This PR retires the td method for most (I need another pass) passes in the Conversion directory.
2024-08-28Reapply "[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) ↵Christopher Bate
dialects on LLVM Dialect and LLVM Core in CMake build (#104832)" (#105703) Reapply the commit 43b508566799751aa180f1eaaafc5be693f2f1ae with additional fixes for building with BUILD_SHARED_LIBS=ON.
2024-08-20Revert "[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) ↵Christopher Bate
dialects on LLVM Dialect and LLVM Core in CMake build (#104832)" This reverts commit 43b508566799751aa180f1eaaafc5be693f2f1ae since it caused the build to break with BUILD_SHARED_LIBS=ON.
2024-08-19[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) dialects on ↵Christopher Bate
LLVM Dialect and LLVM Core in CMake build (#104832) This change removes dependencies declared as either 'LINK_LIBS' or 'LINK_COMPONENTS' across several MLIR libraries. The removed dependencies appear to be incorrect and may have been required in older versions of the project. These dependencies cause many high level dialects to have transitive dependence on the LLVM dialect and the LLVM 'Core' library ('llvm/lib/IR'). Note that if using the 'Ninja' CMake generator, one can inspect the dependencies (including all transitive libraries) of any given MLIR target but using the command `ninja -C <build dir> -t browse` and navigating to the library of interest in a web browser.
2024-02-28[mlir] Fix shared builds. NFCMichael Liao
2024-02-28[mlir][affine] Enable ConvertAffineToStandard pass to handle ↵Rishabh Bali
affine.delinearize_index Op. (#82189) This PR, aims to enable the `ConvertAffineToStandard` to handle `affine.dilinearize_index` Operation. Fixes #78458
2024-02-21[mlir] Use arith max or min ops instead of cmp + select (#82178)mlevesquedion
I believe the semantics should be the same, but this saves 1 op and simplifies the code. For example, the following two instructions: ``` %2 = cmp sgt %0, %1 %3 = select %2, %0, %1 ``` Are equivalent to: ``` %2 = maxsi %0 %1 ```
2023-12-20[mlir][SCF] `scf.parallel`: Make reductions part of the terminator (#75314)Matthias Springer
This commit makes reductions part of the terminator. Instead of `scf.yield`, `scf.reduce` now terminates the body of `scf.parallel` ops. `scf.reduce` may contain an arbitrary number of reductions, with one region per reduction. Example: ```mlir %init = arith.constant 0.0 : f32 %r:2 = scf.parallel (%iv) = (%lb) to (%ub) step (%step) init (%init, %init) -> f32, f32 { %elem_to_reduce1 = load %buffer1[%iv] : memref<100xf32> %elem_to_reduce2 = load %buffer2[%iv] : memref<100xf32> scf.reduce(%elem_to_reduce1, %elem_to_reduce2 : f32, f32) { ^bb0(%lhs : f32, %rhs: f32): %res = arith.addf %lhs, %rhs : f32 scf.reduce.return %res : f32 }, { ^bb0(%lhs : f32, %rhs: f32): %res = arith.mulf %lhs, %rhs : f32 scf.reduce.return %res : f32 } } ``` `scf.reduce` operations can no longer be interleaved with other ops in the body of `scf.parallel`. This simplifies the op and makes it possible to assign the `RecursiveMemoryEffects` trait to `scf.reduce`. (This was not possible before because the op was not a terminator, causing the op to be DCE'd.)
2023-09-29[mlir][Affine][NFC] Define AffineForOp operands in ODS (#67694)Matthias Springer
Modernize affine dialect ops: Define LB, UB, step and inits as operands in TableGen.
2023-09-21[mlir][Interfaces] `LoopLikeOpInterface`: Add helpers to get region ↵Matthias Springer
iter_args and inits (#66925) `AffineForOp::getInitOperands` is renamed to `getInits` to be consistent with MLIR operand getter naming conventions. ("get" + operand name)
2023-05-12[mlir] Move casting calls from methods to function callsTres Popp
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Caveats include: - This clang-tidy script probably has more problems. - This only touches C++ code, so nothing that is being generated. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This first patch was created with the following steps. The intention is to only do automated changes at first, so I waste less time if it's reverted, and so the first mass change is more clear as an example to other teams that will need to follow similar steps. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. 4. Some changes have been deleted for the following reasons: - Some files had a variable also named cast - Some files had not included a header file that defines the cast functions - Some files are definitions of the classes that have the casting methods, so the code still refers to the method instead of the function without adding a prefix or removing the method declaration at the same time. ``` ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\ mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\ mlir/lib/**/IR/\ mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\ mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\ mlir/test/lib/Dialect/Test/TestTypes.cpp\ mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\ mlir/test/lib/Dialect/Test/TestAttributes.cpp\ mlir/unittests/TableGen/EnumsGenTest.cpp\ mlir/test/python/lib/PythonTestCAPI.cpp\ mlir/include/mlir/IR/ ``` Differential Revision: https://reviews.llvm.org/D150123
2023-04-20[mlir][Affine][NFC] Wrap dialect in "affine" namespaceMatthias Springer
This cleanup aligns the affine dialect with all the other dialects. Differential Revision: https://reviews.llvm.org/D148687
2023-01-12[mlir] Add operations to BlockAndValueMapping and rename it to IRMappingJeff Niu
The patch adds operations to `BlockAndValueMapping` and renames it to `IRMapping`. When operations are cloned, old operations are mapped to the cloned operations. This allows mapping from an operation to a cloned operation. Example: ``` Operation *opWithRegion = ... Operation *opInsideRegion = &opWithRegion->front().front(); IRMapping map Operation *newOpWithRegion = opWithRegion->clone(map); Operation *newOpInsideRegion = map.lookupOrNull(opInsideRegion); ``` Migration instructions: All includes to `mlir/IR/BlockAndValueMapping.h` should be replaced with `mlir/IR/IRMapping.h`. All uses of `BlockAndValueMapping` need to be renamed to `IRMapping`. Reviewed By: rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D139665
2023-01-10Move from llvm::makeArrayRef to ArrayRef deduction guides - last partserge-sans-paille
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files. Differential Revision: https://reviews.llvm.org/D141298
2022-12-17mlir/tblgen: use std::optional in generationRamkumar Ramachandra
This is part of an effort to migrate from llvm::Optional to std::optional. This patch changes the way mlir-tblgen generates .inc files, and modifies tests and documentation appropriately. It is a "no compromises" patch, and doesn't leave the user with an unpleasant mix of llvm::Optional and std::optional. A non-trivial change has been made to ControlFlowInterfaces to split one constructor into two, relating to a build failure on Windows. See also: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Signed-off-by: Ramkumar Ramachandra <r@artagnon.com> Differential Revision: https://reviews.llvm.org/D138934
2022-12-02[mlir] Remove support for non-prefixed accessorsRiver Riddle
This finishes off a year long pursuit to LLVMify the generated operation accessors, prefixing them with get/set. Support for any other accessor naming is fully removed after this commit. https://discourse.llvm.org/t/psa-raw-accessors-are-being-removed/65629 Differential Revision: https://reviews.llvm.org/D136727
2022-09-29[mlir][arith] Change dialect name from Arithmetic to ArithJakub Kuderski
Suggested by @lattner in https://discourse.llvm.org/t/rfc-define-precise-arith-semantics/65507/22. Tested with: `ninja check-mlir check-mlir-integration check-mlir-mlir-spirv-cpu-runner check-mlir-mlir-vulkan-runner check-mlir-examples` and `bazel build --config=generic_clang @llvm-project//mlir:all`. Reviewed By: lattner, Mogball, rriddle, jpienaar, mehdi_amini Differential Revision: https://reviews.llvm.org/D134762
2022-09-18[mlir] Use x.empty() instead of llvm::empty(x) (NFC)Kazu Hirata
I'm planning to deprecate and eventually remove llvm::empty. Note that no use of llvm::empty requires the ability of llvm::empty to determine the emptiness from begin/end only.
2022-08-31[MLIR] Update pass declarations to new autogenerated filesMichele Scuttari
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-30Revert "[MLIR] Update pass declarations to new autogenerated files"Michele Scuttari
This reverts commit 2be8af8f0e0780901213b6fd3013a5268ddc3359.
2022-08-30[MLIR] Update pass declarations to new autogenerated filesMichele Scuttari
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-06-26[mlir] Flip more uses to prefixed accessor form (NFC).Jacques Pienaar
Try to keep the final flip small. Need to flip MemRef as there are many templated cases with it and Tensor.
2022-06-20[mlir] Don't use Optional::getValue (NFC)Kazu Hirata
2022-06-20Don't use Optional::hasValue (NFC)Kazu Hirata
2022-06-20[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyAlex Zinenko
This aligns the SCF dialect file layout with the majority of the dialects. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D128049
2022-06-18[mlir] Start migrating more dialects to prefixed formJacques Pienaar
Marked all dialects that could be (reasonably) easily flipped to _Both prefix. Updating the accessors to prefixed form will happen in follow up, this was to flush out conflicts and to mark all dialects explicitly as I plan to flip OpBase default to _Prefixed to avoid needing to migrate new dialects. Except for Standalone example which got flipped to _Prefixed. Differential Revision: https://reviews.llvm.org/D128027
2022-06-13[mlir] (NFC) Clean up bazel and CMake target namesMogball
All dialect targets in bazel have been named *Dialect and all dialect targets in CMake have been named MLIR*Dialect.
2022-03-01[mlir] Trim a huge number of unnecessary dependencies on the Func dialectRiver Riddle
The Func has a large number of legacy dependencies carried over from the old Standard dialect, which was pervasive and contained a large number of varied operations. With the split of the standard dialect and its demise, a lot of lingering dead dependencies have survived to the Func dialect. This commit removes a large majority of then, greatly reducing the dependence surface area of the Func dialect.
2022-03-01[mlir] Rename the Standard dialect to the Func dialectRiver Riddle
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the initial renaming (which by itself is already huge), but there are a large number of cleanups unlocked/necessary afterwards: * Removing a bunch of unnecessary dependencies on Func * Cleaning up the From/ToStandard conversion passes * Preparing for the move of FuncOp to the Func dialect See the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061 Differential Revision: https://reviews.llvm.org/D120624
2022-02-10[MLIR][NFC] Move expandAffineMap/Expr out to Affine utilsUday Bondhugula
Move expandAffineMap and expandAffineApplyExpr out to AffineUtils. This is a useful method. The child revision uses it. NFC. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D119401
2022-02-02[mlir] Move SelectOp from Standard to ArithmeticRiver Riddle
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion. Differential Revision: https://reviews.llvm.org/D118648
2022-01-31[mlir][vector][NFC] Split into IR, Transforms and UtilsMatthias Springer
This reduces the dependencies of the MLIRVector target and makes the dialect consistent with other dialects. Differential Revision: https://reviews.llvm.org/D118533
2022-01-24[mlir] Add missing dependencies after D118062River Riddle
These used to be covered transitively, but now need to be explicit.
2021-12-30[MLIR] Move AtomicRMW into MemRef dialect and enum into ArithWilliam S. Moses
Per the discussion in https://reviews.llvm.org/D116345 it makes sense to move AtomicRMWOp out of the standard dialect. This was accentuated by the need to add a fold op with a memref::cast. The only dialect that would permit this is the memref dialect (keeping it in the standard dialect or moving it to the arithmetic dialect would require those dialects to have a dependency on the memref dialect, which breaks linking). As the AtomicRMWKind enum is used throughout, this has been moved to Arith. Reviewed By: Mogball Differential Revision: https://reviews.llvm.org/D116392
2021-12-20[mlir] Switching accessors to prefixed form (NFC)Jacques Pienaar
Makes eventual prefixing flag flip smaller change.
2021-12-08Adjust "end namespace" comment in MLIR to match new agree'd coding styleMehdi Amini
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html Differential Revision: https://reviews.llvm.org/D115309
2021-10-13[MLIR] Replace std ops with arith dialect opsMogball
Precursor: https://reviews.llvm.org/D110200 Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects. Renamed all instances of operations in the codebase and in tests. Reviewed By: rriddle, jpienaar Differential Revision: https://reviews.llvm.org/D110797
2021-05-05[mlir][Affine][Vector] Support vectorizing reduction loopsSergei Grechanik
This patch adds support for vectorizing loops with 'iter_args' implementing known reductions along the vector dimension. Comparing to the non-vector-dimension case, two additional things are done during vectorization of such loops: - The resulting vector returned from the loop is reduced to a scalar using `vector.reduce`. - In some cases a mask is applied to the vector yielded at the end of the loop to prevent garbage values from being written to the accumulator. Vectorization of reduction loops is disabled by default. To enable it, a map from loops to array of reduction descriptors should be explicitly passed to `vectorizeAffineLoops`, or `vectorize-reductions=true` should be passed to the SuperVectorize pass. Current limitations: - Loops with a non-unit step size are not supported. - n-D vectorization with n > 1 is not supported. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D100694
2021-04-29[mlir] support max/min lower/upper bounds in affine.parallelAlex Zinenko
This enables to express more complex parallel loops in the affine framework, for example, in cases of tiling by sizes not dividing loop trip counts perfectly or inner wavefront parallelism, among others. One can't use affine.max/min and supply values to the nested loop bounds since the results of such affine.max/min operations aren't valid symbols. Making them valid symbols isn't an option since they would introduce selection trees into memref subscript arithmetic as an unintended and undesired consequence. Also add support for converting such loops to SCF. Drop some API that isn't used in the core repo from AffineParallelOp since its semantics becomes ambiguous in presence of max/min bounds. Loop normalization is currently unavailable for such loops. Depends On D101171 Reviewed By: bondhugula Differential Revision: https://reviews.llvm.org/D101172
2021-04-06[mlir] Fix support for lowering non-32-bit affine reductions.Alex Zinenko
The existing implementation was always creating 32-bit constants for floating-point and integer reductions regardless of the actual type, which resulted in invalid IR being generated for any types other than f32 and i32 when lowering affine.parallel to SCF. Use the actual type instead. Reviewed By: chelini Differential Revision: https://reviews.llvm.org/D99942
2021-03-22[PatternMatch] Big mechanical rename OwningRewritePatternList -> ↵Chris Lattner
RewritePatternSet and insert -> add. NFC This doesn't change APIs, this just cleans up the many in-tree uses of these names to use the new preferred names. We'll keep the old names around for a couple weeks to help transitions. Differential Revision: https://reviews.llvm.org/D99127
2021-03-21Change OwningRewritePatternList to carry an MLIRContext with it.Chris Lattner
This updates the codebase to pass the context when creating an instance of OwningRewritePatternList, and starts removing extraneous MLIRContext parameters. There are many many more to be removed. Differential Revision: https://reviews.llvm.org/D99028
2021-03-17[MLIR] Fix lowering of Affine IfOp in the presence of yield values.Gaurav Shukla
This commit fixes the lowering of `Affine.IfOp` to `SCF.IfOp` in the presence of yield values. These changes have been made as a part of `-lower-affine` pass. Differential Revision: https://reviews.llvm.org/D98760
2021-03-15[MLIR] Create memref dialect and move dialect-specific ops from std.Julian Gross
Create the memref dialect and move dialect-specific ops from std dialect to this dialect. Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp AssumeAlignmentOp -> MemRef_AssumeAlignmentOp DeallocOp -> MemRef_DeallocOp DimOp -> MemRef_DimOp MemRefCastOp -> MemRef_CastOp MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp LoadOp -> MemRef_LoadOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp SubViewOp -> MemRef_SubViewOp TransposeOp -> MemRef_TransposeOp TensorLoadOp -> MemRef_TensorLoadOp TensorStoreOp -> MemRef_TensorStoreOp TensorToMemRefOp -> MemRef_BufferCastOp ViewOp -> MemRef_ViewOp The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667 Differential Revision: https://reviews.llvm.org/D98041
2021-02-18Revert "[MLIR] Create memref dialect and move several dialect-specific ops ↵Alexander Belyaev
from std." This commit introduced a cyclic dependency: Memref dialect depends on Standard because it used ConstantIndexOp. Std depends on the MemRef dialect in its EDSC/Intrinsics.h Working on a fix. This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.
2021-02-18[MLIR] Create memref dialect and move several dialect-specific ops from std.Julian Gross
Create the memref dialect and move several dialect-specific ops without dependencies to other ops from std dialect to this dialect. Moved ops: AllocOp -> MemRef_AllocOp AllocaOp -> MemRef_AllocaOp DeallocOp -> MemRef_DeallocOp MemRefCastOp -> MemRef_CastOp GetGlobalMemRefOp -> MemRef_GetGlobalOp GlobalMemRefOp -> MemRef_GlobalOp PrefetchOp -> MemRef_PrefetchOp ReshapeOp -> MemRef_ReshapeOp StoreOp -> MemRef_StoreOp TransposeOp -> MemRef_TransposeOp ViewOp -> MemRef_ViewOp The roadmap to split the memref dialect from std is discussed here: https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667 Differential Revision: https://reviews.llvm.org/D96425
2021-02-12[mlir][Vector] Introduce 'vector.load' and 'vector.store' opsDiego Caballero
This patch adds the 'vector.load' and 'vector.store' ops to the Vector dialect [1]. These operations model *contiguous* vector loads and stores from/to memory. Their semantics are similar to the 'affine.vector_load' and 'affine.vector_store' counterparts but without the affine constraints. The most relevant feature is that these new vector operations may perform a vector load/store on memrefs with a non-vector element type, unlike 'std.load' and 'std.store' ops. This opens the representation to model more generic vector load/store scenarios: unaligned vector loads/stores, perform scalar and vector memory access on the same memref, decouple memory allocation constraints from memory accesses, etc [1]. These operations will also facilitate the progressive lowering of both Affine vector loads/stores and Vector transfer reads/writes for those that read/write contiguous slices from/to memory. In particular, this patch adds the 'vector.load' and 'vector.store' ops to the Vector dialect, implements their lowering to the LLVM dialect, and changes the lowering of 'affine.vector_load' and 'affine.vector_store' ops to the new vector ops. The lowering of Vector transfer reads/writes will be implemented in the future, probably as an independent pass. The API of 'vector.maskedload' and 'vector.maskedstore' has also been changed slightly to align it with the transfer read/write ops and the vector new ops. This will improve reusability among all these operations. For example, the lowering of 'vector.load', 'vector.store', 'vector.maskedload' and 'vector.maskedstore' to the LLVM dialect is implemented with a single template conversion pattern. [1] https://llvm.discourse.group/t/memref-type-and-data-layout/ Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D96185
2021-02-04[mlir] Mark LogicalResult as LLVM_NODISCARDRiver Riddle
This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was always the intention from the beginning, but got lost along the way. Differential Revision: https://reviews.llvm.org/D95841