#
67b9d3ff |
| 21-Jan-2025 |
Matthias Gehre <matthias.gehre@amd.com> |
[mlir] computeSliceParameters: Fix offset when m(0) != 0 (#122492)
For affine maps where `m(0) != 0`,
like `affine_map<(d0) -> (d0 + 3)` in
```
%generic = linalg.generic
{indexing_maps = [
[mlir] computeSliceParameters: Fix offset when m(0) != 0 (#122492)
For affine maps where `m(0) != 0`,
like `affine_map<(d0) -> (d0 + 3)` in
```
%generic = linalg.generic
{indexing_maps = [affine_map<(d0) -> (d0 + 3)>,
affine_map<(d0) -> (d0)>],
iterator_types = ["parallel"]} ins(%arg0: tensor<9xf32>) outs(%empty : tensor<6xf32>) {
^bb0(%in : f32, %out: f32):
linalg.yield %in : f32
} -> tensor<6xf32>
```
tiling currently computes the wrong slice offsets. When tiling above
example with a size of 3, it would compute
```
scf.for %i = ...
%slice = tensor.extract_slice %arg0[%i + 3] [6] [1]
linalg.generic
{indexing_maps = [affine_map<(d0) -> (d0 + 3)>,
affine_map<(d0) -> (d0)>],
iterator_types = ["parallel"]} ins(%slice: tensor<6xf32>)
```
and thus apply the `+3` twice (once in the extract slice and a second
time in the linalg.generic).
This PR fixes this to yield an offset of
`tensor.extract_slice %arg0[%i] [6] [1]` instead.
show more ...
|
#
28039055 |
| 26-Sep-2024 |
Hugo Trachino <hugo.trachino@huawei.com> |
[MLIR][Transform] Hoist Pad generates linalg.transpose (#109669)
For readability purpose, generate linalg named ops when possible.
For maintainability purpose, get rid of duplicated code.
|
#
d5f0969c |
| 12-Sep-2024 |
MaheshRavishankar <1663364+MaheshRavishankar@users.noreply.github.com> |
[mlir][TilingInterface] Avoid looking at operands for getting slices to continue tile + fuse. (#107882)
Current implementation of `scf::tileConsumerAndFuseProducerUsingSCF`
looks at operands of til
[mlir][TilingInterface] Avoid looking at operands for getting slices to continue tile + fuse. (#107882)
Current implementation of `scf::tileConsumerAndFuseProducerUsingSCF`
looks at operands of tiled/tiled+fused operations to see if they are
produced by `extract_slice` operations to populate the worklist used to
continue fusion. This implicit assumption does not always work. Instead
make the implementations of `getTiledImplementation` return the slices
to use to continue fusion.
This is a breaking change
- To continue to get the same behavior of
`scf::tileConsumerAndFuseProducerUsingSCF`, change all out-of-tree
implementation of `TilingInterface::getTiledImplementation` to return
the slices to continue fusion on. All in-tree implementations have been
adapted to this.
- This change touches parts that required a simplification to the
`ControlFn` in `scf::SCFTileAndFuseOptions`. It now returns a
`std::optional<scf::SCFTileAndFuseOptions::ControlFnResult>` object that
should be `std::nullopt` if fusion is not to be performed.
Signed-off-by: MaheshRavishankar <mahesh.revishankar@gmail.com>
show more ...
|
#
5262865a |
| 04-Aug-2024 |
Kazu Hirata <kazu@google.com> |
[mlir] Construct SmallVector with ArrayRef (NFC) (#101896)
|
#
59a92019 |
| 07-Mar-2024 |
Matthias Springer <me@m-sp.org> |
[mlir][IR] Make `replaceOp` / `replaceAllUsesWith` API consistent (#82629)
* `replaceOp` replaces all uses of the original op and erases the old
op.
* `replaceAllUsesWith` replaces all uses of the
[mlir][IR] Make `replaceOp` / `replaceAllUsesWith` API consistent (#82629)
* `replaceOp` replaces all uses of the original op and erases the old
op.
* `replaceAllUsesWith` replaces all uses of the original op/value/block.
It does not erase any IR.
This commit renames `replaceOpWithIf` to `replaceUsesWithIf`.
`replaceOpWithIf` was a misnomer because the function never erases the
original op. Similarly, `replaceOpWithinBlock` is renamed to
`replaceUsesWithinBlock`. (No "operation replaced" is sent because the
op is not erased.)
Also improve comments.
show more ...
|
#
91d5653e |
| 24-Feb-2024 |
Matthias Springer <me@m-sp.org> |
[mlir] Use `OpBuilder::createBlock` in op builders and patterns (#82770)
When creating a new block in (conversion) rewrite patterns,
`OpBuilder::createBlock` must be used. Otherwise, no
`notifyBlo
[mlir] Use `OpBuilder::createBlock` in op builders and patterns (#82770)
When creating a new block in (conversion) rewrite patterns,
`OpBuilder::createBlock` must be used. Otherwise, no
`notifyBlockInserted` notification is sent to the listener.
Note: The dialect conversion relies on listener notifications to keep
track of IR modifications. Creating blocks without the builder API can
lead to memory leaks during rollback.
show more ...
|
#
fe8a62c4 |
| 08-Feb-2024 |
Uday Bondhugula <uday@polymagelabs.com> |
[MLIR] Fix crash in AffineMap::replace for zero result maps (#80930)
Fix obvious bug in AffineMap::replace for the case of zero result maps.
Extend/complete inferExprsFromList to work with empty ex
[MLIR] Fix crash in AffineMap::replace for zero result maps (#80930)
Fix obvious bug in AffineMap::replace for the case of zero result maps.
Extend/complete inferExprsFromList to work with empty expression lists.
show more ...
|
#
0a8e3dd4 |
| 12-Jan-2024 |
Matthias Springer <me@m-sp.org> |
[mlir][Interfaces] `DestinationStyleOpInterface`: Rename `hasTensor/BufferSemantics` (#77574)
Rename interface functions as follows:
* `hasTensorSemantics` -> `hasPureTensorSemantics`
* `hasBuffer
[mlir][Interfaces] `DestinationStyleOpInterface`: Rename `hasTensor/BufferSemantics` (#77574)
Rename interface functions as follows:
* `hasTensorSemantics` -> `hasPureTensorSemantics`
* `hasBufferSemantics` -> `hasPureBufferSemantics`
These two functions return "true" if the op has tensor/buffer operands
but not buffer/tensor operands.
Also drop the "ranked" part from the interface, i.e., do not distinguish
between ranked/unranked types.
The new function names describe the functions more accurately. They also
align their semantics with the notion of "tensor semantics" with the
bufferization framework. (An op is supposed to be bufferized if it has
tensor operands, and we don't care if it also has memref operands.)
This change is in preparation of #75273, which adds
`BufferizableOpInterface::hasTensorSemantics`. By renaming the functions
in the `DestinationStyleOpInterface`, we can avoid name clashes between
the two interfaces.
show more ...
|
#
1609f1c2 |
| 14-Nov-2023 |
long.chen <lipracer@gmail.com> |
[mlir][affine][nfc] cleanup deprecated T.cast style functions (#71269)
detail see the docment: https://mlir.llvm.org/deprecation/
Not all changes are made manually, most of them are made through
[mlir][affine][nfc] cleanup deprecated T.cast style functions (#71269)
detail see the docment: https://mlir.llvm.org/deprecation/
Not all changes are made manually, most of them are made through a clang
tool I wrote https://github.com/lipracer/cpp-refactor.
show more ...
|
#
0b2197b0 |
| 21-Sep-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][Interfaces] Clean up `DestinationStyleOpInterface` (#67015)
* "init" operands are specified with `MutableOperandRange` (which gives
access to the underlying `OpOperand *`). No more magic num
[mlir][Interfaces] Clean up `DestinationStyleOpInterface` (#67015)
* "init" operands are specified with `MutableOperandRange` (which gives
access to the underlying `OpOperand *`). No more magic numbers.
* Remove most interface methods and make them helper functions. Only
`getInitsMutable` should be implemented.
* Provide separate helper functions for accessing mutable/immutable
operands (`OpOperand`/`Value`, in line with #66515): `getInitsMutable`
and `getInits` (same naming convention as auto-generated op accessors).
`getInputOperands` was not renamed because this function cannot return a
`MutableOperandRange` (because the operands are not necessarily
consecutive). `OpOperandVector` is no longer needed.
* The new `getDpsInits`/`getDpsInitsMutable` is more efficient than the
old `getDpsInitOperands` because no `SmallVector` is created. The new
functions return a range of operands.
* Fix a bug in `getDpsInputOperands`: out-of-bounds operands were
potentially returned.
show more ...
|
#
cb7bda2a |
| 04-Jul-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][NFC] Use `getConstantIntValue` instead of casting to `ConstantIndexOp`
`getConstantIntValue` extracts constant values from all constant-like ops, not just `arith::ConstantIndexOp`.
Different
[mlir][NFC] Use `getConstantIntValue` instead of casting to `ConstantIndexOp`
`getConstantIntValue` extracts constant values from all constant-like ops, not just `arith::ConstantIndexOp`.
Differential Revision: https://reviews.llvm.org/D154356
show more ...
|
#
f8e59b09 |
| 03-Jul-2023 |
Quentin Colombet <quentin.colombet@gmail.com> |
[mlir][arith] Move getNeutralElement from Linalg utils to arith
This consolidates where this kind of implementations lives and refactor the code to have more code sharing.
NFC
Differential Revisio
[mlir][arith] Move getNeutralElement from Linalg utils to arith
This consolidates where this kind of implementations lives and refactor the code to have more code sharing.
NFC
Differential Revision: https://reviews.llvm.org/D154362
show more ...
|
#
98d6ab9d |
| 27-Jun-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][Linalg] Refactor isaContractionOpInterface and surrounding utils
This is almost NFC except for the fact that: - when multiple candidates are available we now return them in sorted order vs un
[mlir][Linalg] Refactor isaContractionOpInterface and surrounding utils
This is almost NFC except for the fact that: - when multiple candidates are available we now return them in sorted order vs undetermined order previously - the type of the transform return is relaxed an a test is added for the case where the transform does not apply
Differential Revision: https://reviews.llvm.org/D153941
show more ...
|
#
f8b8affc |
| 27-Jun-2023 |
Nicolas Vasilache <nicolasvasilache@users.noreply.github.com> |
[mlir][Linalg]Add support for inferring batch dimensions
|
#
68f58812 |
| 26-May-2023 |
Tres Popp <tpopp@google.com> |
[mlir] Move casting calls from methods to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionali
[mlir] Move casting calls from methods to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent.
Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call.
Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443
Implementation: This patch updates all remaining uses of the deprecated functionality in mlir/. This was done with clang-tidy as described below and further modifications to GPUBase.td and OpenMPOpsInterfaces.td.
Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state.
``` ninja -C $BUILD_DIR clang-tidy
run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix
rm -rf $BUILD_DIR/tools/mlir/**/*.inc ```
Differential Revision: https://reviews.llvm.org/D151542
show more ...
|
#
5550c821 |
| 08-May-2023 |
Tres Popp <tpopp@google.com> |
[mlir] Move casting calls from methods to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionali
[mlir] Move casting calls from methods to function calls
The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent.
Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call.
Caveats include: - This clang-tidy script probably has more problems. - This only touches C++ code, so nothing that is being generated.
Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443
Implementation: This first patch was created with the following steps. The intention is to only do automated changes at first, so I waste less time if it's reverted, and so the first mass change is more clear as an example to other teams that will need to follow similar steps.
Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. 4. Some changes have been deleted for the following reasons: - Some files had a variable also named cast - Some files had not included a header file that defines the cast functions - Some files are definitions of the classes that have the casting methods, so the code still refers to the method instead of the function without adding a prefix or removing the method declaration at the same time.
``` ninja -C $BUILD_DIR clang-tidy
run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix
rm -rf $BUILD_DIR/tools/mlir/**/*.inc
git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\ mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\ mlir/lib/**/IR/\ mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\ mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\ mlir/test/lib/Dialect/Test/TestTypes.cpp\ mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\ mlir/test/lib/Dialect/Test/TestAttributes.cpp\ mlir/unittests/TableGen/EnumsGenTest.cpp\ mlir/test/python/lib/PythonTestCAPI.cpp\ mlir/include/mlir/IR/ ```
Differential Revision: https://reviews.llvm.org/D150123
show more ...
|
#
6089d612 |
| 16-Apr-2023 |
Rahul Kayaith <rkayaith@gmail.com> |
[mlir] Prevent implicit downcasting to interfaces
Currently conversions to interfaces may happen implicitly (e.g. `Attribute -> TypedAttr`), failing a runtime assert if the interface isn't actually
[mlir] Prevent implicit downcasting to interfaces
Currently conversions to interfaces may happen implicitly (e.g. `Attribute -> TypedAttr`), failing a runtime assert if the interface isn't actually implemented. This change marks the `Interface(ValueT)` constructor as explicit so that a cast is required.
Where it was straightforward to I adjusted code to not require casts, otherwise I just made them explicit.
Depends on D148491, D148492
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D148493
show more ...
|
#
4c48f016 |
| 20-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][Affine][NFC] Wrap dialect in "affine" namespace
This cleanup aligns the affine dialect with all the other dialects.
Differential Revision: https://reviews.llvm.org/D148687
|
#
cf9e88ff |
| 13-Apr-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Linalg] NFC - Extract an IndexingUtils from Linalg/Utils
Differential Revision: https://reviews.llvm.org/D148201
|
#
eabb6ccd |
| 11-Apr-2023 |
Matthias Springer <springerm@google.com> |
[mlir][linalg] Replace `getUpperBoundForIndex` implementation
Use `reifyValueBound` instead, which is more general not hard-coded to a specific list supported ops.
Also add a `closedUB` parameter t
[mlir][linalg] Replace `getUpperBoundForIndex` implementation
Use `reifyValueBound` instead, which is more general not hard-coded to a specific list supported ops.
Also add a `closedUB` parameter to the ValueBoundsOpInterface API.
Differential Revision: https://reviews.llvm.org/D146356
show more ...
|
#
352d6fe1 |
| 27-Mar-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Linalg] NFC - Move transform utilities related to subcomputation inference to Linalg/Utils
|
#
47bff1cc |
| 23-Mar-2023 |
Matthias Springer <me@m-sp.org> |
[mlir][Analysis][NFC] Make BoundType a top-level enum
`BoundType` is no longer a nested member of `IntegerRelation` but a top-level enum in the `presburger` namespace.
This allows `BoundType` to be
[mlir][Analysis][NFC] Make BoundType a top-level enum
`BoundType` is no longer a nested member of `IntegerRelation` but a top-level enum in the `presburger` namespace.
This allows `BoundType` to be predeclared in header files. Nested members cannot be predeclared.
Differential Revision: https://reviews.llvm.org/D146210
show more ...
|
#
96179dff |
| 15-Feb-2023 |
Nicolas Vasilache <nicolas.vasilache@gmail.com> |
[mlir][Linalg] Add a transform dialect op to rewrite ops to destination passing style.
A new transform dialect op is introduced to perform the rewrite. The test pass option is now obsolete and is re
[mlir][Linalg] Add a transform dialect op to rewrite ops to destination passing style.
A new transform dialect op is introduced to perform the rewrite. The test pass option is now obsolete and is removed in favor of the transform.
In the process I realized the tensor.pad nofold attribute was not taken into account and added support to emit a bufferization.alloc_tensor + linalg.copy.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D143943
show more ...
|
#
7301a7ce |
| 06-Feb-2023 |
Andrzej Warzynski <andrzej.warzynski@gmail.com> |
[mlir][linalg] Make Linalg vectorizer lower affine.apply
As discussed in [1], it is possible that the input to the Linalg vectorizer contains `affine.apply` ops. Such operations are not vectarizable
[mlir][linalg] Make Linalg vectorizer lower affine.apply
As discussed in [1], it is possible that the input to the Linalg vectorizer contains `affine.apply` ops. Such operations are not vectarizable at the moment, but this can be fixed by simply converting them to arithmetic operations. This is basically what this patch introduces.
The IR change enabled in this patch could be part of a larger set of "linalgOp pre-processing" transformations that happens right before vectorization starts but after we know we can vectorize the op. I am leaving this as a TODO.
[1] https://github.com/iree-org/iree/issues/10876
Differential Revision: https://reviews.llvm.org/D143429
Co-authored-by: Thomas Raoux <thomasraoux@google.com>
show more ...
|
#
f4535890 |
| 04-Feb-2023 |
Diego Caballero <diegocaballero@google.com> |
Revert "[mlir][linalg] Make Linalg vectorizer lower affine.apply"
This reverts commit c7b1176e9afbfcc3da9482abbf7c1eb8793ff254.
|