History log of /llvm-project-15.0.7/mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp (Results 1 – 25 of 144)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


123456