[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.
[mlir] move SCF headers to SCF/{IR,Transforms} respectivelyThis aligns the SCF dialect file layout with the majority of the dialects.Reviewed By: jpienaarDifferential Revision: https://reviews.llvm.org/D128049
show more ...
[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir][NFC] Replace some llvm::find with llvm::is_contained.This patch replaces some llvm::find with llvm::is_contained, it should be more clear.Differential Revision: https://reviews.llvm.org/D1
[mlir][NFC] Replace some llvm::find with llvm::is_contained.This patch replaces some llvm::find with llvm::is_contained, it should be more clear.Differential Revision: https://reviews.llvm.org/D127077
[MLIR][OpenMP] Place alloca scope within wsloop in scf.parallel to omp loweringhttps://reviews.llvm.org/D120423 replaced the use of stacksave/restore with memref.alloca_scope, but kept the save/res
[MLIR][OpenMP] Place alloca scope within wsloop in scf.parallel to omp loweringhttps://reviews.llvm.org/D120423 replaced the use of stacksave/restore with memref.alloca_scope, but kept the save/restore at the same location. This PR places the allocation scope within the wsloop, thus keeping the same allocation scope as the original scf.parallel (e.g. no longer over stack allocating).Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D120772
[mlir] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and conta
[mlir] Trim a huge number of unnecessary dependencies on the Func dialectThe Func has a large number of legacy dependencies carried over from the oldStandard dialect, which was pervasive and contained a large number of variedoperations. With the split of the standard dialect and its demise, a lot of lingeringdead dependencies have survived to the Func dialect. This commit removes alarge majority of then, greatly reducing the dependence surface area of theFunc dialect.
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialectThe last remaining operations in the standard dialect all revolve aroundFuncOp/function related constructs. This patch simply handles the initialrenaming (which by itself is already huge), but there are a large numberof 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 dialectSee the discussion at https://discourse.llvm.org/t/standard-dialect-the-final-chapter/6061Differential Revision: https://reviews.llvm.org/D120624
[SCF][MemRef] Enable SCF.Parallel Lowering to use Scope OpAs discussed in https://reviews.llvm.org/D119743 scf.parallel would continuously stack allocate since the alloca op was placd in the wsloop
[SCF][MemRef] Enable SCF.Parallel Lowering to use Scope OpAs discussed in https://reviews.llvm.org/D119743 scf.parallel would continuously stack allocate since the alloca op was placd in the wsloop rather than the omp.parallel. This PR is the second stage of the fix for that problem. Specifically, we now introduce an alloca scope around the inlined body of the scf.parallel and enable a canonicalization to hoist the allocations to the surrounding allocation scope (e.g. omp.parallel).Reviewed By: ftynseDifferential Revision: https://reviews.llvm.org/D120423
[mlir] Move SelectOp from Standard to ArithmeticThis is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.Differenti
[mlir] Move SelectOp from Standard to ArithmeticThis 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
[mlir] Make locations required when adding/creating block argumentsBlockArguments gained the ability to have locations attached a while ago, but theyhave always been optional. This goes against th
[mlir] Make locations required when adding/creating block argumentsBlockArguments gained the ability to have locations attached a while ago, but theyhave always been optional. This goes against the core tenant of MLIR where locationinformation is a requirement, so this commit updates the API to require locations.Fixes #53279Differential Revision: https://reviews.llvm.org/D117633
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/AnalysisThe current state of the top level Analysis/ directory is that it contains two libraries;a generic Analysis library (free fr
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/AnalysisThe current state of the top level Analysis/ directory is that it contains two libraries;a generic Analysis library (free from dialect dependencies), and a LoopAnalysis librarythat contains various analysis utilities that originated from Affine loop transformations.This commit moves the LoopAnalysis to the more appropriate home of `Dialect/Affine/Analysis/`,given the use and intention of the majority of the code within it. After the move, if thereare generic utilities that would fit better in the top-level Analysis/ directory, we can movethem.Differential Revision: https://reviews.llvm.org/D117351
[mlir] Switching accessors to prefixed form (NFC)Makes eventual prefixing flag flip smaller change.
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferenti
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferential Revision: https://reviews.llvm.org/D115309
[mlir] Update accessors prefixed form (NFC)
[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.Followinghttps://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis
[mlir] Switch arith, llvm, std & shape dialects to accessors prefixed both form.Followinghttps://llvm.discourse.group/t/psa-ods-generated-accessors-will-change-to-have-a-get-prefix-update-you-apis/4476,this follows flipping these dialects to _Both prefixed form. Thischanges the accessors to have a prefix. This was possibly mostly withoutbreaking breaking changes if the existing convenience methods were used.(https://github.com/jpienaar/llvm-project/blob/main/clang-tools-extra/clang-tidy/misc/AddGetterCheck.cppwas used to migrate the callers post flipping, using the output fromOperator.cpp)Differential Revision: https://reviews.llvm.org/D112383
[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed
[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed 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, jpienaarDifferential Revision: https://reviews.llvm.org/D110797
[mlir] Create a generic reduction detection utilityThis patch introduces a generic reduction detection utility that worksacross different dialecs. It is mostly a generalization of the reductionde
[mlir] Create a generic reduction detection utilityThis patch introduces a generic reduction detection utility that worksacross different dialecs. It is mostly a generalization of the reductiondetection 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 andreturns: 1) the reduced value, and 2) a list with the combiner operations.The logic to match reductions involving multiple combiner operations disableduntil we can properly test it.Reviewed By: ftynse, bondhugula, nicolasvasilache, pifon2aDifferential Revision: https://reviews.llvm.org/D110303
[mlir] support reductions in SCF to OpenMP conversionOpenMP reductions need a neutral element, so we match some known reductionkinds (integer add/mul/or/and/xor, float add/mul, integer and float m
[mlir] support reductions in SCF to OpenMP conversionOpenMP reductions need a neutral element, so we match some known reductionkinds (integer add/mul/or/and/xor, float add/mul, integer and float min/max) todefine the neutral element and the atomic version when possible to expressusing atomicrmw (everything except float mul). The SCF-to-OpenMP pass becomes amodule pass because it now needs to introduce new symbols for reductiondeclarations in the module.Reviewed By: cheliniDifferential Revision: https://reviews.llvm.org/D107549
[MLIR][OMP] Ensure nested scf.parallel execute all iterationsPresently, the lowering of nested scf.parallel loops to OpenMP creates one omp.parallel region, with two (nested) OpenMP worksharing loo
[MLIR][OMP] Ensure nested scf.parallel execute all iterationsPresently, the lowering of nested scf.parallel loops to OpenMP creates one omp.parallel region, with two (nested) OpenMP worksharing loops on the inside. When lowered to LLVM and executed, this results in incorrect results. The reason for this is as follows:An OpenMP parallel region results in the code being run with whatever number of threads available to OpenMP. Within a parallel region a worksharing loop divides up the total number of requested iterations by the available number of threads, and distributes accordingly. For a single ws loop in a parallel region, this works as intended.Now consider nested ws loops as follows:omp.parallel { A: omp.ws %i = 0...10 { B: omp.ws %j = 0...10 { code(%i, %j) } }}Suppose we ran this on two threads. The first workshare loop would decide to execute iterations 0, 1, 2, 3, 4 on thread 0, and iterations 5, 6, 7, 8, 9 on thread 1. The second workshare loop would decide the same for its iteration. This means thread 0 would execute i \in [0, 5) and j \in [0, 5). Thread 1 would execute i \in [5, 10) and j \in [5, 10). This means that iterations i in [5, 10), j in [0, 5) and i in [0, 5), j in [5, 10) never get executed, which is clearly wrong.This permits two options for a remedy:1) Change the semantics of the omp.wsloop to be distinct from that of the OpenMP runtime call or equivalently #pragma omp for. This could then allow some lowering transformation to remedy the aforementioned issue. I don't think this is desirable for an abstraction standpoint.2) When lowering an scf.parallel always surround the wsloop with a new parallel region (thereby causing the innermost wsloop to use the number of threads available only to it).This PR implements the latter change.Reviewed By: jdoerfertDifferential Revision: https://reviews.llvm.org/D108426
Rename FrozenRewritePatternList -> FrozenRewritePatternSet; NFC.This nicely aligns the naming with RewritePatternSet. This type isn'tas widely used, but we keep a using declaration in to help wit
Rename FrozenRewritePatternList -> FrozenRewritePatternSet; NFC.This nicely aligns the naming with RewritePatternSet. This type isn'tas widely used, but we keep a using declaration in to help withdownstream consumption of this change.Differential Revision: https://reviews.llvm.org/D99131
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFCThis doesn't change APIs, this just cleans up the many in-tree uses of thesenames to use t
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFCThis doesn't change APIs, this just cleans up the many in-tree uses of thesenames to use the new preferred names. We'll keep the old names around for acouple weeks to help transitions.Differential Revision: https://reviews.llvm.org/D99127
Change OwningRewritePatternList to carry an MLIRContext with it.This updates the codebase to pass the context when creating an instance ofOwningRewritePatternList, and starts removing extraneous M
Change OwningRewritePatternList to carry an MLIRContext with it.This updates the codebase to pass the context when creating an instance ofOwningRewritePatternList, and starts removing extraneous MLIRContextparameters. There are many many more to be removed.Differential Revision: https://reviews.llvm.org/D99028
[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.Reviewed By: silvas, rriddleDifferential R
[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.Reviewed By: silvas, rriddleDifferential Revision: https://reviews.llvm.org/D92878
Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.Given that OpState already implicit converts to Operator*, this seems reasonable.The alternative w
Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.Given that OpState already implicit converts to Operator*, this seems reasonable.The alternative would be to add more functions to OpState which forward to Operation.Reviewed By: rriddle, ftynseDifferential Revision: https://reviews.llvm.org/D92266
[mlir] Add conversion from SCF parallel loops to OpenMPIntroduce a conversion pass from SCF parallel loops to OpenMP dialectconstructs - parallel region and workshare loop. Loops with reductions a
[mlir] Add conversion from SCF parallel loops to OpenMPIntroduce a conversion pass from SCF parallel loops to OpenMP dialectconstructs - parallel region and workshare loop. Loops with reductions are notsupported because the OpenMP dialect cannot model them yet.The conversion currently targets only one level of parallelism, i.e. onlyone top-level `omp.parallel` operation is produced even if there are nested`scf.parallel` operations that could be mapped to `omp.wsloop`. Nestedparallelism support is left for future work.Reviewed By: kiranchandramohanDifferential Revision: https://reviews.llvm.org/D91982