|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
c27d8152 |
| 14-Jul-2022 |
Kazu Hirata <[email protected]> |
[mlir] Use value instead of getValue (NFC)
|
| #
491d2701 |
| 13-Jul-2022 |
Kazu Hirata <[email protected]> |
[mlir] Use has_value instead of hasValue (NFC)
|
| #
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
| #
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
58ceae95 |
| 18-Apr-2022 |
River Riddle <[email protected]> |
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespace
FuncOp has been moved to the `func` namespace for a little over a month, the using directive can be dropped now.
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
1f971e23 |
| 28-Feb-2022 |
River Riddle <[email protected]> |
[mlir] Trim a huge number of unnecessary dependencies on the Func dialect
The Func has a large number of legacy dependencies carried over from the old Standard dialect, which was pervasive and conta
[mlir] Trim a huge number of unnecessary dependencies on the Func dialect
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.
show more ...
|
| #
23aa5a74 |
| 26-Feb-2022 |
River Riddle <[email protected]> |
[mlir] Rename the Standard dialect to the Func dialect
The last remaining operations in the standard dialect all revolve around FuncOp/function related constructs. This patch simply handles the init
[mlir] Rename the Standard dialect to the Func dialect
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
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
a70aa7bb |
| 21-Jan-2022 |
River Riddle <[email protected]> |
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilities
This has been a major TODO for a very long time, and is necessary for establishing a proper dialect-free dep
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilities
This has been a major TODO for a very long time, and is necessary for establishing a proper dialect-free dependency layering for the Transforms library. Code was moved to effectively two 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.h Transforms/LoopUtils.h -> Dialect/Affine/LoopUtils.h Transforms/Utils.h -> Dialect/Affine/Utils.h
The following transforms were also moved: AffineLoopFusion, AffinePipelineDataTransfer, LoopCoalescing
* SCF/ Only one SCF pass was in Transforms/ (likely accidentally placed here): ParallelLoopCollapsing The SCF specific utilities in LoopUtils have been moved to SCF/Utils.h
* Misc: mlir::moveLoopInvariantCode was also moved to LoopLikeInterface.h given that it is a simple utility defined in terms of LoopLikeOpInterface.
Differential Revision: https://reviews.llvm.org/D117848
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
41574554 |
| 04-Jan-2022 |
River Riddle <[email protected]> |
[mlir][Pass] Deprecate FunctionPass in favor of OperationPass<FuncOp>
The only benefit of FunctionPass is that it filters out function declarations. 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 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
show more ...
|
| #
755dc07d |
| 15-Jan-2022 |
River Riddle <[email protected]> |
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/Analysis
The 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/Analysis
The 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 library that 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 there are generic utilities that would fit better in the top-level Analysis/ directory, we can move them.
Differential Revision: https://reviews.llvm.org/D117351
show more ...
|
| #
05f6e939 |
| 13-Jan-2022 |
Uday Bondhugula <[email protected]> |
[MLIR] NFC. affine data copy generate utility return value cleanup
Clean up return value on affineDataCopyGenerate utility. Return the actual success/failure status instead of the "number of bytes"
[MLIR] NFC. affine data copy generate utility return value cleanup
Clean up return value on affineDataCopyGenerate utility. Return the actual success/failure status instead of the "number of bytes" which isn't being used in the codebase in any way. The success/failure status wasn't being sent out earlier.
Differential Revision: https://reviews.llvm.org/D117209
show more ...
|
| #
be0a7e9f |
| 07-Dec-2021 |
Mehdi Amini <[email protected]> |
Adjust "end namespace" comment in MLIR to match new agree'd coding style
See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html
Differenti
Adjust "end namespace" comment in MLIR to match new agree'd coding style
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
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
a54f4eae |
| 12-Oct-2021 |
Mogball <[email protected]> |
[MLIR] Replace std ops with arith dialect ops
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects.
Renamed
[MLIR] Replace std ops with arith dialect ops
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
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
7932d21f |
| 18-Jul-2021 |
Uday Bondhugula <[email protected]> |
[MLIR] Introduce a new rewrite driver to simplify supplied list of ops
Introduce a new rewrite driver (MultiOpPatternRewriteDriver) to rewrite a supplied list of ops and other ops. Provide a knob to
[MLIR] Introduce a new rewrite driver to simplify supplied list of ops
Introduce a new rewrite driver (MultiOpPatternRewriteDriver) to rewrite a supplied list of ops and other ops. Provide a knob to restrict rewrites strictly to those ops or also to affected ops (but still not to completely related ops).
This rewrite driver is commonly needed to run any simplification and cleanup at the end of a transforms pass or transforms utility in a way that only simplifies relevant IR. This makes it easy to write test cases while not performing unrelated whole IR simplification that may invalidate other state at the caller.
The introduced utility provides more freedom to developers of transforms and transform utilities to perform focussed and local simplification. In several cases, it provides greater efficiency as well as more simplification when compared to repeatedly calling `applyOpPatternsAndFold`; in other cases, it avoids the need to undesirably call `applyPatternsAndFoldGreedily` to do unrelated simplification in a FuncOp.
Update a few transformations that were earlier using applyOpPatternsAndFold (SimplifyAffineStructures, affineDataCopyGenerate, a linalg transform).
TODO: - OpPatternRewriteDriver can be removed as it's a special case of MultiOpPatternRewriteDriver, i.e., both can be merged.
Differential Revision: https://reviews.llvm.org/D106232
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
| #
66f878ce |
| 21-Jun-2021 |
Matthias Springer <[email protected]> |
[mlir][NFC] Remove Standard dialect dependency on MemRef dialect
* Remove dependency: Standard --> MemRef * Add dependencies: GPUToNVVMTransforms --> MemRef, Linalg --> MemRef, MemRef --> Tensor * N
[mlir][NFC] Remove Standard dialect dependency on MemRef dialect
* Remove dependency: Standard --> MemRef * Add dependencies: GPUToNVVMTransforms --> MemRef, Linalg --> MemRef, MemRef --> Tensor * Note: The `subtensor_insert_propagate_dest_cast` test case in MemRef/canonicalize.mlir will be moved to Tensor/canonicalize.mlir in a subsequent commit, which moves over the remaining Tensor ops from the Standard dialect to the Tensor dialect.
Differential Revision: https://reviews.llvm.org/D104506
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
1fbb484e |
| 07-May-2021 |
Julian Gross <[email protected]> |
[WIP][mlir] Resolve memref dependency in canonicalize pass.
Splitting the memref dialect lead to an introduction of several dependencies to avoid compilation issues. The canonicalize pass also depen
[WIP][mlir] Resolve memref dependency in canonicalize pass.
Splitting the memref dialect lead to an introduction of several dependencies to avoid compilation issues. The canonicalize pass also depends on the memref dialect, but it shouldn't. This patch resolves the dependencies and the unintuitive includes are removed. However, the dependency moves to the constructor of the std dialect.
Differential Revision: https://reviews.llvm.org/D102060
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
79d7f618 |
| 23-Mar-2021 |
Chris Lattner <[email protected]> |
Rename FrozenRewritePatternList -> FrozenRewritePatternSet; NFC.
This nicely aligns the naming with RewritePatternSet. This type isn't as 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't as widely used, but we keep a using declaration in to help with downstream consumption of this change.
Differential Revision: https://reviews.llvm.org/D99131
show more ...
|
| #
dc4e913b |
| 22-Mar-2021 |
Chris Lattner <[email protected]> |
[PatternMatch] Big mechanical rename OwningRewritePatternList -> RewritePatternSet and insert -> add. NFC
This doesn't change APIs, this just cleans up the many in-tree uses of these names to use t
[PatternMatch] Big mechanical rename OwningRewritePatternList -> 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
show more ...
|
| #
3a506b31 |
| 20-Mar-2021 |
Chris Lattner <[email protected]> |
Change OwningRewritePatternList to carry an MLIRContext with it.
This updates the codebase to pass the context when creating an instance of OwningRewritePatternList, 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 of OwningRewritePatternList, and starts removing extraneous MLIRContext parameters. There are many many more to be removed.
Differential Revision: https://reviews.llvm.org/D99028
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2 |
|
| #
e2310704 |
| 10-Feb-2021 |
Julian Gross <[email protected]> |
[MLIR] Create memref dialect and move dialect-specific ops from std.
Create the memref dialect and move dialect-specific ops from std dialect to this dialect.
Moved ops: AllocOp -> MemRef_AllocOp A
[MLIR] Create memref dialect and move dialect-specific ops from std.
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
show more ...
|
| #
fe7c0d90 |
| 09-Feb-2021 |
River Riddle <[email protected]> |
[mlir][IR] Remove the concept of `OperationProperties`
These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days
[mlir][IR] Remove the concept of `OperationProperties`
These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days. Most of these properties are already checked via traits in most of the code. It is better to align the system around traits, and improve the performance/cost of traits in general.
Differential Revision: https://reviews.llvm.org/D96088
show more ...
|
| #
e21adfa3 |
| 04-Feb-2021 |
River Riddle <[email protected]> |
[mlir] Mark LogicalResult as LLVM_NODISCARD
This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was al
[mlir] Mark LogicalResult as LLVM_NODISCARD
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
show more ...
|
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
3fffffa8 |
| 27-Oct-2020 |
River Riddle <[email protected]> |
[mlir][Pattern] Add a new FrozenRewritePatternList class
This class represents a rewrite pattern list that has been frozen, and thus immutable. This replaces the uses of OwningRewritePatternList in
[mlir][Pattern] Add a new FrozenRewritePatternList class
This class represents a rewrite pattern list that has been frozen, and thus immutable. This replaces the uses of OwningRewritePatternList in pattern driver related API, such as dialect conversion. When PDL becomes more prevalent, this API will allow for optimizing a set of patterns once without the need to do this per run of a pass.
Differential Revision: https://reviews.llvm.org/D89104
show more ...
|
| #
b6eb26fd |
| 27-Oct-2020 |
River Riddle <[email protected]> |
[mlir][NFC] Move around the code related to PatternRewriting to improve layering
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those
[mlir][NFC] Move around the code related to PatternRewriting to improve layering
There are several pieces of pattern rewriting infra in IR/ that really shouldn't be there. This revision moves those pieces to a better location such that they are easier to evolve in the future(e.g. with PDL). More concretely this revision does the following:
* Create a Transforms/GreedyPatternRewriteDriver.h and move the apply*andFold methods there. The definitions for these methods are already in Transforms/ so it doesn't make sense for the declarations to be in IR.
* Create a new lib/Rewrite library and move PatternApplicator there. This new library will be focused on applying rewrites, and will also include compiling rewrites with PDL.
Differential Revision: https://reviews.llvm.org/D89103
show more ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1 |
|
| #
ec85d7c8 |
| 15-Jul-2020 |
Uday Bondhugula <[email protected]> |
[MLIR][NFC] Fix clang tidy warnings in misc utilities
Fix clang tidy warnings in misc utilities - missing const or a star in declaration.
Differential Revision: https://reviews.llvm.org/D83861
|