[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][scf] Add option to loop pipelining to not peel the epilogueAdd an option to predicate the epilogue within the kernel instead ofpeeling the epilogue. This is a useful option to prevent gener
[mlir][scf] Add option to loop pipelining to not peel the epilogueAdd an option to predicate the epilogue within the kernel instead ofpeeling the epilogue. This is a useful option to prevent generatinglarge amount of code for deep pipeline. This currently require a userlamdba to implement operation predication.Differential Revision: https://reviews.llvm.org/D126753
[mlir][SCF] Retire `cloneWithNewYields` helper function.This is now subsumed by `replaceLoopWithNewYields`.Differential Revision: https://reviews.llvm.org/D125309
[mlir][SCF] Add utility method to add new yield values to a loop.The current implementation of `cloneWithNewYields` has a few issues- It clones the loop body of the original loop to create a new
[mlir][SCF] Add utility method to add new yield values to a loop.The current implementation of `cloneWithNewYields` has a few issues- It clones the loop body of the original loop to create a new loop. This is very expensive.- It performs `erase` operations which are incompatible when this method is called from within a pattern rewrite. All erases need to go through `PatternRewriter`.To address these a new utility method `replaceLoopWithNewYields` is addedwhich- moves the operations from the original loop into the new loop.- replaces all uses of the original loop with the corresponding results of the new loop- use a call back to allow caller to generate the new yield values.- the original loop is modified to just yield the basic block arguments corresponding to the iter_args of the loop. This represents a no-op loop. The loop itself is dead (since all its uses are replaced), but is not removed. The caller is expected to erase the op. Consequently, this method can be called from within a `matchAndRewrite` method of a `PatternRewriter`.The `cloneWithNewYields` could be replaces with`replaceLoopWithNewYields`, but that seems to trigger a failure duringwalks, potentially due to the operations being moved. That is left asa TODO.Differential Revision: https://reviews.llvm.org/D125147
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespaceFuncOp has been moved to the `func` namespace for a little over a month, theusing directive can be dropped now.
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implici
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implicit" fallback path to use the name of the type, instead of usinga static template variable (which breaks shared libraries). The major downside to thisis that it adds some additional initialization costs for the implicit path. Given theuse of type names for uniqueness in the fallback, we also no longer allow typesdefined in anonymous namespaces to have an implicit TypeID. To simplify definingan ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macrowas added to allow for explicitly defining a TypeID directly on an internal class.To help identify when types are using the fallback, `-debug-only=typeid` can beused to log which types are using implicit ids.This change generally only requires changes to the test passes, which are all definedin anonymous namespaces, and thus can't use the fallback any longer.Differential Revision: https://reviews.llvm.org/D122775
[mlir:PassOption] Rework ListOption parsing and add support for std::vector/SmallVector optionsListOption currently uses llvm::cl::list under the hood, but the usagesof ListOption are generally a
[mlir:PassOption] Rework ListOption parsing and add support for std::vector/SmallVector optionsListOption currently uses llvm::cl::list under the hood, but the usagesof ListOption are generally a tad different from llvm::cl::list. Thiscommit codifies this by making ListOption implicitly comma separated,and removes the explicit flag set for all of the current list options.The new parsing for comma separation of ListOption also adds in supportfor skipping over delimited sub-ranges (i.e. {}, [], (), "", ''). Thismore easily supports nested options that use those as part of theformat, and this constraint (balanced delimiters) is already codifiedin the syntax of pass pipelines.See https://discourse.llvm.org/t/list-of-lists-pass-option/5950 forrelated discussionDifferential Revision: https://reviews.llvm.org/D122879
[mlir] Simplify LoopLikeOpInterface- Adds default implementations of `isDefinedOutsideOfLoop` and `moveOutOfLoop` since 99% of all implementations of these functions were identical- `moveOutOfLoop
[mlir] Simplify LoopLikeOpInterface- Adds default implementations of `isDefinedOutsideOfLoop` and `moveOutOfLoop` since 99% of all implementations of these functions were identical- `moveOutOfLoop` takes one operation and doesn't return anything anymore. 100% of all implementations of this function would always return `success` and uses would either respond with a pass failure or an `llvm_unreachable`.
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made
[mlir] Move the Builtin FuncOp to the Func dialectThis commit moves FuncOp out of the builtin dialect, and into the Funcdialect. This move has been planned in some capacity from the momentwe made FuncOp an operation (years ago). This commit handles thefunctional aspects of the move, but various aspects are left untouchedto ease migration: func::FuncOp is re-exported into mlir to reducethe actual API churn, the assembly format still accepts the unqualified`func`. These temporary measures will remain for a little while tosimplify migration before being removed.Differential Revision: https://reviews.llvm.org/D121266
[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfacesA lot of test passes are currently anchored on FuncOp, but thisdependencyis generally just historical. A m
[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfacesA lot of test passes are currently anchored on FuncOp, but thisdependencyis generally just historical. A majority of these test passes can run onany operation, or can operate on a specific interface(FunctionOpInterface/SymbolOpInterface).This allows for greatly reducing the API dependency on FuncOp, whichis slated to be moved out of the Builtin dialect.Differential Revision: https://reviews.llvm.org/D121191
[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
[mlir][scf] Add callback to annotate ops during pipeliningThis allow user to register a callback that can annotate operationsduring software pipelining. This allows user potential annotate op tok
[mlir][scf] Add callback to annotate ops during pipeliningThis allow user to register a callback that can annotate operationsduring software pipelining. This allows user potential annotate op toknow what part of the pipeline they correspond to.Differential Revision: https://reviews.llvm.org/D119866
Remove spurious includes and dependencies from Bazel files (NFC)Differential Revision: https://reviews.llvm.org/D119526
[mlir] Move SCF utils implementations to SCF/Utils.BEGIN_PUBLIC[mlir] Move SCF utils implementations to SCF/Utils.END_PUBLIC
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilitiesThis has been a major TODO for a very long time, and is necessary for establishing a properdialect-free dep
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilitiesThis has been a major TODO for a very long time, and is necessary for establishing a properdialect-free dependency layering for the Transforms library. Code was moved to effectivelytwo main locations:* Affine/There was quite a bit of affine dialect related code in Transforms/ do to historical reasons(of a time way into MLIR's past). The following headers were moved to:Transforms/LoopFusionUtils.h -> Dialect/Affine/LoopFusionUtils.hTransforms/LoopUtils.h -> Dialect/Affine/LoopUtils.hTransforms/Utils.h -> Dialect/Affine/Utils.hThe following transforms were also moved:AffineLoopFusion, AffinePipelineDataTransfer, LoopCoalescing* SCF/Only one SCF pass was in Transforms/ (likely accidentally placed here): ParallelLoopCollapsingThe SCF specific utilities in LoopUtils have been moved to SCF/Utils.h* Misc:mlir::moveLoopInvariantCode was also moved to LoopLikeInterface.h giventhat it is a simple utility defined in terms of LoopLikeOpInterface.Differential Revision: https://reviews.llvm.org/D117848
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around,
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>The only benefit of FunctionPass is that it filters out functiondeclarations. This isn't enough to justify carrying it around, as we cansimplify filter out declarations when necessary within the pass. We canalso explore with better scheduling primitives to filter out declarationsat the pipeline level in the future.The definition of FunctionPass is left intact for now to allow time for downstreamusers to migrate.Differential Revision: https://reviews.llvm.org/D117182
[mlir][scf] NFC - refactor the implementation of outlineIfOpThis revision refactors the implementation of outlineIfOp to exposea finer-grain functionality `outlineSingleBlockRegion` that will ber
[mlir][scf] NFC - refactor the implementation of outlineIfOpThis revision refactors the implementation of outlineIfOp to exposea finer-grain functionality `outlineSingleBlockRegion` that will bereused in other contexts.Differential Revision: https://reviews.llvm.org/D116591
[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] Add software pipelining transformation for scf.For opThis is the first step to support software pipeline for scf.for loops.This is only the transformation to create pipelined kernel andpro
[mlir] Add software pipelining transformation for scf.For opThis is the first step to support software pipeline for scf.for loops.This is only the transformation to create pipelined kernel andprologue/epilogue.The scheduling needs to be given by user as many different algorithmand heuristic could be applied.This currently doesn't handle loop arguments, this will be added in afollow up patch.Differential Revision: https://reviews.llvm.org/D105868
Migrate MLIR test passes to the new registration APIMake sure they all define getArgument()/getDescription().Depends On D104421Differential Revision: https://reviews.llvm.org/D104426
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part o
[mlir][NFC] Move passes in test/lib/Transforms/ to a directory that mirrors what they testtest/lib/Transforms/ has bitrot and become somewhat of a dumping grounds for testing pretty much any part of the project. This revision cleans this up, and moves the files within to a directory that reflects what is actually being tested.Differential Revision: https://reviews.llvm.org/D102456