summaryrefslogtreecommitdiff
path: root/mlir/lib/Dialect/SCF/Transforms/ParallelLoopTiling.cpp
AgeCommit message (Collapse)Author
2025-07-25[mlir][NFC] Use `getDefiningOp<OpTy>()` instead of ↵Longsheng Mou
`dyn_cast<OpTy>(getDefiningOp())` (#150428) This PR uses `val.getDefiningOp<OpTy>()` to replace `dyn_cast<OpTy>(val.getDefiningOp())` , `dyn_cast_or_null<OpTy>(val.getDefiningOp())` and `dyn_cast_if_present<OpTy>(val.getDefiningOp())`.
2025-07-24[mlir][NFC] update `mlir/Dialect` create APIs (20/n) (#149927)Maksim Levental
See https://github.com/llvm/llvm-project/pull/147168 for more info.
2025-06-23switch type and value ordering for arith `Constant[XX]Op` (#144636)Skrai Pardus
This change standardizes the order of the parameters for `Constant[XXX] Ops` to match with all other `Op` `build()` constructors. In all instances of generated code for the MLIR dialects's Ops (that is the TableGen using the .td files to create the .h.inc/.cpp.inc files), the desired result type is always specified before the value. Examples: ``` // ArithOps.h.inc class ConstantOp : public ::mlir::Op<ConstantOp, ::mlir::OpTrait::ZeroRegions, ::mlir::OpTrait::OneResult, ::mlir::OpTrait::OneTypedResult<::mlir::Type>::Impl, ::mlir::OpTrait::ZeroSuccessors, ::mlir::OpTrait::ZeroOperands, ::mlir::OpTrait::OpInvariants, ::mlir::BytecodeOpInterface::Trait, ::mlir::OpTrait::ConstantLike, ::mlir::ConditionallySpeculatable::Trait, ::mlir::OpTrait::AlwaysSpeculatableImplTrait, ::mlir::MemoryEffectOpInterface::Trait, ::mlir::OpAsmOpInterface::Trait, ::mlir::InferIntRangeInterface::Trait, ::mlir::InferTypeOpInterface::Trait> { public: .... static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type result, ::mlir::TypedAttr value); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::TypedAttr value); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes, ::mlir::TypedAttr value); static void build(::mlir::OpBuilder &, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes = {}); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes = {}); ... ``` ``` // ArithOps.h.inc class SubIOp : public ::mlir::Op<SubIOp, ::mlir::OpTrait::ZeroRegions, ::mlir::OpTrait::OneResult, ::mlir::OpTrait::OneTypedResult<::mlir::Type>::Impl, ::mlir::OpTrait::ZeroSuccessors, ::mlir::OpTrait::NOperands<2>::Impl, ::mlir::OpTrait::OpInvariants, ::mlir::BytecodeOpInterface::Trait, ::mlir::ConditionallySpeculatable::Trait, ::mlir::OpTrait::AlwaysSpeculatableImplTrait, ::mlir::MemoryEffectOpInterface::Trait, ::mlir::InferIntRangeInterface::Trait, ::mlir::arith::ArithIntegerOverflowFlagsInterface::Trait, ::mlir::OpTrait::SameOperandsAndResultType, ::mlir::VectorUnrollOpInterface::Trait, ::mlir::OpTrait::Elementwise, ::mlir::OpTrait::Scalarizable, ::mlir::OpTrait::Vectorizable, ::mlir::OpTrait::Tensorizable, ::mlir::InferTypeOpInterface::Trait> { public: ... static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type result, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlagsAttr overflowFlags); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlagsAttr overflowFlags); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlagsAttr overflowFlags); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Type result, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlags overflowFlags = ::mlir::arith::IntegerOverflowFlags::none); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlags overflowFlags = ::mlir::arith::IntegerOverflowFlags::none); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes, ::mlir::Value lhs, ::mlir::Value rhs, ::mlir::arith::IntegerOverflowFlags overflowFlags = ::mlir::arith::IntegerOverflowFlags::none); static void build(::mlir::OpBuilder &, ::mlir::OperationState &odsState, ::mlir::TypeRange resultTypes, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes = {}); static void build(::mlir::OpBuilder &odsBuilder, ::mlir::OperationState &odsState, ::mlir::ValueRange operands, ::llvm::ArrayRef<::mlir::NamedAttribute> attributes = {}); ... ``` In comparison, in the distinct case of `ConstantIntOp` and `ConstantFloatOp`, the ordering of the result type and the value is switched. Thus, this PR corrects the ordering of the aforementioned `Constant[XXX]Ops` to match with other constructors.
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-10-23[MLIR][scf.parallel] Don't allow a tile size of 0 (#68762)Justin Fargnoli
Fix a crash reported in #64331. The crash is described in the following comment: > It looks like the bug is being caused by the command line argument --scf-parallel-loop-tiling=parallel-loop-tile-sizes=0. More specifically, --scf-parallel-loop-tiling=parallel-loop-tile-sizes sets the tileSize variable to 0 on [this line](https://github.com/llvm/llvm-project/blob/7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd/mlir/lib/Dialect/SCF/Transforms/ParallelLoopTiling.cpp#L67). tileSize is then used on [this line](https://github.com/llvm/llvm-project/blob/7cc1bfaf371c4a816cf4e62fe31d8515bf8f6fbd/mlir/lib/Dialect/SCF/Transforms/ParallelLoopTiling.cpp#L117) causing a divide by zero exception. This PR will: 1. Call `signalPassFail()` when 0 is passed as a tile size. 2. Avoid the divide by zero that causes the crash. Note: This is my first PR for MLIR, so please liberally critique it.
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
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-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-08-29[mlir] Add `Block::eraseArguments` that erases a subrangeJeff Niu
This patch adds a an `eraseArguments` function that erases a subrange of a block's arguments. This can be used inplace of the terrible pattern ``` block->eraseArguments(llvm::to_vector(llvm::seq(...))); ``` Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D132890
2022-08-09[mlir] Use C++17 structured bindings instead of std::tie where applicable. NFCIBenjamin Kramer
2022-06-26[mlir] Generalize SCF passes to not have to run on FuncOp.Stella Laurenzo
Seems to have been an accident of history and none of these had any reason to be restricted to FuncOp. Differential Revision: https://reviews.llvm.org/D128614
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-07[MLIR][SCF] Fix top-level comment (NFC)lorenzo chelini
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-01-28[mlir] Move SCF utils implementations to SCF/Utils.Adrian Kuegel
BEGIN_PUBLIC [mlir] Move SCF utils implementations to SCF/Utils. END_PUBLIC
2022-01-18[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>River Riddle
The only benefit of FunctionPass is that it filters out function declarations. This isn't enough to justify carrying it around, as we can simplify filter out declarations when necessary within the pass. We can also explore with better scheduling primitives to filter out declarations at the pipeline level in the future. The definition of FunctionPass is left intact for now to allow time for downstream users to migrate. Differential Revision: https://reviews.llvm.org/D117182
2022-01-02Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)Mehdi Amini
2021-12-20[mlir] Switching accessors to prefixed form (NFC)Jacques Pienaar
Makes eventual prefixing flag flip smaller change.
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-08-16[MLIR][DISC] Revise ParallelLoopTilingPass with inbound_check modetashuang.zk
Expand ParallelLoopTilingPass with an inbound_check mode. In default mode, the upper bound of the inner loop is from the min op; in inbound_check mode, the upper bound of the inner loop is the step of the outer loop and an additional inbound check will be emitted inside of the inner loop. This was 'FIXME' in the original codes and a typical usage is for GPU backends, thus the outer loop and inner loop can be mapped to blocks/threads in seperate. Differential Revision: https://reviews.llvm.org/D105455
2021-05-13[mlir][NFC] Add helper for common pattern of replaceAllUsesExceptSean Silva
This covers the extremely common case of replacing all uses of a Value with a new op that is itself a user of the original Value. This should also be a little bit more efficient than the `SmallPtrSet<Operation *, 1>{op}` idiom that was being used before. Differential Revision: https://reviews.llvm.org/D102373
2021-02-04[mlir] Return scf.parallel ops resulted from tiling.Alexander Belyaev
Differential Revision: https://reviews.llvm.org/D96024
2021-01-26[mlir][nfc] Move `getInnermostParallelLoops` to SCF/Transforms/Utils.h.Alexander Belyaev
2020-11-27[MLIR][SCF] Find all innermost loops for parallel loop tilingFrederik Gossen
Overcome the assumption that parallel loops are only nested in other parallel loops. Differential Revision: https://reviews.llvm.org/D92188
2020-06-25[mlir] parallel loop tiling optimization for loops with static boundsTobias Gysi
Summary: The patch optimizes the tiling of parallel loops with static bounds if the number of loop iterations is an integer multiple of the tile size. Reviewers: herhut, ftynse, bondhugula Reviewed By: herhut, ftynse Subscribers: bondhugula, mehdi_amini, rriddle, jpienaar, shauheen, antiagainst, nicolasvasilache, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, stephenneuendorffer, Joonsoo, grosul1, frgossen, Kayjukh, jurahul, msifontes Tags: #mlir Differential Revision: https://reviews.llvm.org/D82003
2020-06-22[mlir] Add for loop specializationStephan Herhut
Summary: We already had a parallel loop specialization pass that is used to enable unrolling and consecutive vectorization by rewriting loops whose bound is defined as a min of a constant and a dynamic value into a loop with static bound (the constant) and the minimum as bound, wrapped into a conditional to dispatch between the two. This adds the same rewriting for for loops. Differential Revision: https://reviews.llvm.org/D82189
2020-06-17[MLIR] Fix parallel loop tiling.Stephan Herhut
Summary: Parallel loop tiling did not properly compute the updated loop indices when tiling, which lead to wrong results. Differential Revision: https://reviews.llvm.org/D82013
2020-05-13[mlir] Change dialect namespace loop->scfAlex Zinenko
All ops of the SCF dialect now use the `scf.` prefix instead of `loop.`. This is a part of dialect renaming. Differential Revision: https://reviews.llvm.org/D79844
2020-05-11[mlir] NFC: Rename LoopOps dialect to SCF (Structured Control Flow)Alex Zinenko
This dialect contains various structured control flow operaitons, not only loops, reflect this in the name. Drop the Ops suffix for consistency with other dialects. Note that this only moves the files and changes the C++ namespace from 'loop' to 'scf'. The visible IR prefix remains the same and will be updated separately. The conversions will also be updated separately. Differential Revision: https://reviews.llvm.org/D79578
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-17 21:47:31 +0000