History log of /llvm-project/mlir/lib/Dialect/Linalg/Utils/Utils.cpp (Results 1 – 25 of 177)
Revision Date Author Comments
# 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.


12345678