|
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 |
|
| #
380a1b20 |
| 23-Jul-2022 |
Kazu Hirata <[email protected]> |
Use callables directly in any_of, count_if, etc (NFC)
|
| #
485190df |
| 15-Jul-2022 |
Mahesh Ravishankar <[email protected]> |
[mlir][Linalg] Deprecate `tileAndFuseLinalgOps` method and associated patterns.
The `tileAndFuseLinalgOps` is a legacy approach for tiling + fusion of Linalg operations. Since it was also intended t
[mlir][Linalg] Deprecate `tileAndFuseLinalgOps` method and associated patterns.
The `tileAndFuseLinalgOps` is a legacy approach for tiling + fusion of Linalg operations. Since it was also intended to work on operations with buffer operands, this method had fairly complex logic to make sure tile and fuse was correct even with side-effecting linalg ops. While complex, it still wasnt robust enough. This patch deprecates this method and thereby deprecating the tiling + fusion method for ops with buffer semantics. Note that the core transformation to do fusion of a producer with a tiled consumer still exists. The deprecation here only removes methods that auto-magically tried to tile and fuse correctly in presence of side-effects.
The `tileAndFuseLinalgOps` also works with operations with tensor semantics. There are at least two other ways the same functionality exists. 1) The `tileConsumerAndFuseProducers` method. This does a similar transformation, but using a slightly different logic to automatically figure out the legal tile + fuse code. Note that this is also to be deprecated soon. 2) The prefered way uses the `TilingInterface` for tile + fuse, and relies on the caller to set the tiling options correctly to ensure that the generated code is correct. As proof that (2) is equivalent to the functionality provided by `tileAndFuseLinalgOps`, relevant tests have been moved to use the interface, where the test driver sets the tile sizes appropriately to generate the expected code.
Differential Revision: https://reviews.llvm.org/D129901
show more ...
|
| #
5a001136 |
| 13-Jul-2022 |
Nicolas Vasilache <[email protected]> |
[mlir][Linalg] Retire LinalgPromotion pattern
This revision removes the LinalgPromotion pattern and adds a `transform.structured.promotion` op. Since the LinalgPromotion transform allows the injecti
[mlir][Linalg] Retire LinalgPromotion pattern
This revision removes the LinalgPromotion pattern and adds a `transform.structured.promotion` op. Since the LinalgPromotion transform allows the injection of arbitrary C++ via lambdas, the current transform op does not handle it. It is left for future work to decide what the right transform op control is for those cases.
Note the underlying implementation remains unchanged and the mechanism is still controllable by lambdas from the API.
During this refactoring it was also determined that the `dynamicBuffers` option does not actually connect to a change of behavior in the algorithm. This also exhibits that the related test is wrong (and dangerous). Both the option and the test are therefore removed.
Lastly, a test that connects patterns using the filter-based mechanism is removed: all the independent pieces are already tested separately.
Context: https://discourse.llvm.org/t/psa-retire-linalg-filter-based-patterns/63785
Differential Revision: https://reviews.llvm.org/D129649
show more ...
|
| #
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)
|
| #
04235d07 |
| 28-Jun-2022 |
Jacques Pienaar <[email protected]> |
[mlir] Update flipped accessors (NFC)
Follow up with memref flipped and flipping any intermediate changes made.
|
| #
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 |
|
| #
6d5fc1e3 |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
[mlir] Don't use Optional::getValue (NFC)
|
| #
0916d96d |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
| #
8b68da2c |
| 17-Jun-2022 |
Alex Zinenko <[email protected]> |
[mlir] move SCF headers to SCF/{IR,Transforms} respectively
This aligns the SCF dialect file layout with the majority of the dialects.
Reviewed By: jpienaar
Differential Revision: https://reviews.
[mlir] move SCF headers to SCF/{IR,Transforms} respectively
This aligns the SCF dialect file layout with the majority of the dialects.
Reviewed By: jpienaar
Differential Revision: https://reviews.llvm.org/D128049
show more ...
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
9a79b1b0 |
| 03-Jun-2022 |
Diego Caballero <[email protected]> |
[mlir] Add peeling xform to Codegen Strategy
This patch adds the knobs to use peeling in the codegen strategy infrastructure.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org
[mlir] Add peeling xform to Codegen Strategy
This patch adds the knobs to use peeling in the codegen strategy infrastructure.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D126842
show more ...
|
| #
ce2e198b |
| 31-May-2022 |
Alex Zinenko <[email protected]> |
[mlir] add decompose and generalize to structured transform ops
These ops complement the tiling/padding transformations by transforming higher-level named structured operations such as depthwise con
[mlir] add decompose and generalize to structured transform ops
These ops complement the tiling/padding transformations by transforming higher-level named structured operations such as depthwise convolutions into lower-level and/or generic equivalents that are better handled by some downstream transformations.
Differential Revision: https://reviews.llvm.org/D126698
show more ...
|
|
Revision tags: llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
eda6f907 |
| 22-Apr-2022 |
River Riddle <[email protected]> |
[mlir][NFC] Shift a bunch of dialect includes from the .h to the .cpp
Now that dialect constructors are generated in the .cpp file, we can drop all of the dependent dialect includes from the .h file
[mlir][NFC] Shift a bunch of dialect includes from the .h to the .cpp
Now that dialect constructors are generated in the .cpp file, we can drop all of the dependent dialect includes from the .h file.
Differential Revision: https://reviews.llvm.org/D124298
show more ...
|
| #
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 |
|
| #
d26c42af |
| 28-Mar-2022 |
gysit <[email protected]> |
[mlir][linalg] Control dimensions to pad.
This revision supports padding only a subset of the iteration dimensions via an additional padding-dimensions parameter. This control allows us to pad an op
[mlir][linalg] Control dimensions to pad.
This revision supports padding only a subset of the iteration dimensions via an additional padding-dimensions parameter. This control allows us to pad an operation in multiple steps. For example, one may want to pad only the output dimensions of a producer matmul fused into a consumer loop nest, before tiling and padding its reduction dimension.
Depends On D122309
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D122560
show more ...
|
| #
58d0da88 |
| 28-Mar-2022 |
gysit <[email protected]> |
[mlir][linalg] Use arrays to pass padding options.
Pass the padding options using arrays instead of lambdas. In particular pass the padding value as string and use the argument parser to create the
[mlir][linalg] Use arrays to pass padding options.
Pass the padding options using arrays instead of lambdas. In particular pass the padding value as string and use the argument parser to create the padding value. Arrays are a more natural choice that matches the current use cases and avoids converting arrays to lambdas.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D122309
show more ...
|
| #
b1b57f81 |
| 24-Mar-2022 |
gysit <[email protected]> |
[mlir][linalg] Support padding LinalgOps in use-def chain.
Previously, only LinalgOps whose operands are defined by an ExtractSliceOp could be padded. The revision supports walking a use-def chain o
[mlir][linalg] Support padding LinalgOps in use-def chain.
Previously, only LinalgOps whose operands are defined by an ExtractSliceOp could be padded. The revision supports walking a use-def chain of LinalgOps to find an ExtractSliceOp.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D122116
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
36550692 |
| 08-Mar-2022 |
River Riddle <[email protected]> |
[mlir] Move the Builtin FuncOp to the Func dialect
This commit moves FuncOp out of the builtin dialect, and into the Func dialect. This move has been planned in some capacity from the moment we made
[mlir] Move the Builtin FuncOp to the Func dialect
This commit moves FuncOp out of the builtin dialect, and into the Func dialect. This move has been planned in some capacity from the moment we made FuncOp an operation (years ago). This commit handles the functional aspects of the move, but various aspects are left untouched to ease migration: func::FuncOp is re-exported into mlir to reduce the actual API churn, the assembly format still accepts the unqualified `func`. These temporary measures will remain for a little while to simplify migration before being removed.
Differential Revision: https://reviews.llvm.org/D121266
show more ...
|
| #
7294be2b |
| 14-Mar-2022 |
gysit <[email protected]> |
[mlir][linalg] Replace linalg.fill by OpDSL variant.
The revision removes the linalg.fill operation and renames the OpDSL generated linalg.fill_tensor operation to replace it. After the change, all
[mlir][linalg] Replace linalg.fill by OpDSL variant.
The revision removes the linalg.fill operation and renames the OpDSL generated linalg.fill_tensor operation to replace it. After the change, all named structured operations are defined via OpDSL and there are no handwritten operations left.
A side-effect of the change is that the pretty printed form changes from: ``` %1 = linalg.fill(%cst, %0) : f32, tensor<?x?xf32> -> tensor<?x?xf32> ``` changes to ``` %1 = linalg.fill ins(%cst : f32) outs(%0 : tensor<?x?xf32>) -> tensor<?x?xf32> ``` Additionally, the builder signature now takes input and output value ranges as it is the case for all other OpDSL operations: ``` rewriter.create<linalg::FillOp>(loc, val, output) ``` changes to ``` rewriter.create<linalg::FillOp>(loc, ValueRange{val}, ValueRange{output}) ``` All other changes remain minimal. In particular, the canonicalization patterns are the same and the `value()`, `output()`, and `result()` methods are now implemented by the FillOpInterface.
Depends On D120726
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D120728
show more ...
|
| #
8d785070 |
| 08-Mar-2022 |
gysit <[email protected]> |
[mlir][linalg] Add returning rewrite method to fusion pattern (NFC).
Enhance `LinalgTileAndFuseTensorOpsPattern` with an additional rewrite signature that returns the result of the rewrite.
Reviewe
[mlir][linalg] Add returning rewrite method to fusion pattern (NFC).
Enhance `LinalgTileAndFuseTensorOpsPattern` with an additional rewrite signature that returns the result of the rewrite.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D121212
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc2 |
|
| #
1a829d2d |
| 28-Feb-2022 |
Alexander Belyaev <[email protected]> |
[mlir] Purge linalg.tiled_loop.
Differential Revision: https://reviews.llvm.org/D119415
|
| #
748bf4bb |
| 25-Feb-2022 |
Hanhan Wang <[email protected]> |
[mlir][Linalg] Add support for tileFuseAndDistribute on tensors.
This extends TileAndFuse to handle distribution on tensors.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D120
[mlir][Linalg] Add support for tileFuseAndDistribute on tensors.
This extends TileAndFuse to handle distribution on tensors.
Reviewed By: gysit
Differential Revision: https://reviews.llvm.org/D120441
show more ...
|
| #
0edb4127 |
| 16-Feb-2022 |
Lei Zhang <[email protected]> |
[mlir][linalg] Add control to pad-slice swap pattern
The pad-slice swap pattern generates `scf.if` and `tensor.generate` to guard against zero-sized slices if it cannot prove the slice is always non
[mlir][linalg] Add control to pad-slice swap pattern
The pad-slice swap pattern generates `scf.if` and `tensor.generate` to guard against zero-sized slices if it cannot prove the slice is always non-zero. This is safe but quite conservative. It can be unnecessary for cases where we know by problem definition such cases does not exist, even if with dynamic shaped ops or unknown tile/slice sizes, e.g., convolution padding size = 1 with kernel dim size = 3.
So this commit introduces a control to the pattern to specify whether to generate the if constructs to handle such cases better, given that once the if constructs is materialized, it's very hard to analyze and simplify.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D117017
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1 |
|
| #
6635c12a |
| 06-Feb-2022 |
Benjamin Kramer <[email protected]> |
[mlir] Use SmallBitVector instead of SmallDenseSet for AffineMap::compressSymbols
This is both more efficient and more ergonomic to use, as inverting a bit vector is trivial while inverting a set is
[mlir] Use SmallBitVector instead of SmallDenseSet for AffineMap::compressSymbols
This is both more efficient and more ergonomic to use, as inverting a bit vector is trivial while inverting a set is annoying.
Sadly this leaks into a bunch of APIs downstream, so adapt them as well.
This would be NFC, but there is an ordering dependency in MemRefOps's computeMemRefRankReductionMask. This is now deterministic, previously it was dependent on SmallDenseSet's unspecified iteration order.
Differential Revision: https://reviews.llvm.org/D119076
show more ...
|