|
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 |
|
| #
aba43035 |
| 23-Jul-2022 |
Dmitri Gribenko <[email protected]> |
Use llvm::sort instead of std::sort where possible
llvm::sort is beneficial even when we use the iterator-based overload, since it can optionally shuffle the elements (to detect non-determinism). Ho
Use llvm::sort instead of std::sort where possible
llvm::sort is beneficial even when we use the iterator-based overload, since it can optionally shuffle the elements (to detect non-determinism). However llvm::sort is not usable everywhere, for example, in compiler-rt.
Reviewed By: nhaehnle
Differential Revision: https://reviews.llvm.org/D130406
show more ...
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
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 ...
|
| #
cf6a7c19 |
| 13-Jun-2022 |
Mahesh Ravishankar <[email protected]> |
[mlir][TilingInterface] Add pattern to tile using TilingInterface and implement TilingInterface for Linalg ops.
This patch adds support for tiling operations that implement the TilingInterface. - It
[mlir][TilingInterface] Add pattern to tile using TilingInterface and implement TilingInterface for Linalg ops.
This patch adds support for tiling operations that implement the TilingInterface. - It separates the loop constructs that are used to iterate over tile from the implementation of the tiling itself. For example, the use of destructive updates is more related to use of scf.for for iterating over tiles that are tensors. - To test the transformation, TilingInterface is implemented for LinalgOps. The separation of the looping constructs used from the implementation of tile code generation greatly simplifies the latter. - The implementation of TilingInterface for LinalgOp is kept as an external model for now till this approach can be fully flushed out to replace the existing tiling + fusion approaches in Linalg.
Differential Revision: https://reviews.llvm.org/D127133
show more ...
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
5f0d4f20 |
| 09-Jun-2022 |
Alex Zinenko <[email protected]> |
[mlir] Introduce Transform ops for loops
Introduce transform ops for "for" loops, in particular for peeling, software pipelining and unrolling, along with a couple of "IR navigation" ops. These ops
[mlir] Introduce Transform ops for loops
Introduce transform ops for "for" loops, in particular for peeling, software pipelining and unrolling, along with a couple of "IR navigation" ops. These ops are intended to be generalized to different kinds of loops when possible and therefore use the "loop" prefix. They currently live in the SCF dialect as there is no clear place to put transform ops that may span across several dialects, this decision is postponed until the ops actually need to handle non-SCF loops.
Additionally refactor some common utilities for transform ops into trait or interface methods, and change the loop pipelining to be a returning pattern.
Reviewed By: springerm
Differential Revision: https://reviews.llvm.org/D127300
show more ...
|
|
Revision tags: llvmorg-14.0.4 |
|
| #
63d69a21 |
| 16-May-2022 |
Mehdi Amini <[email protected]> |
Apply clang-tidy fixes for performance-unnecessary-value-param in Utils.cpp (NFC)
|
| #
a4b227c2 |
| 12-May-2022 |
grosul1 <[email protected]> |
[mlir] Fix loop unrolling: properly replace the arguments of the epilogue loop.
Using "replaceUsesOfWith" is incorrect because the same initializer value may appear multiple times.
For example, if
[mlir] Fix loop unrolling: properly replace the arguments of the epilogue loop.
Using "replaceUsesOfWith" is incorrect because the same initializer value may appear multiple times.
For example, if the epilogue is needed when this loop is unrolled ``` %x:2 = scf.for ... iter_args(%arg1 = %c1, %arg2 = %c1) { ... } ``` then both epilogue's arguments will be incorrectly renamed to use the same result index (note #1 in both cases): ``` %x_unrolled:2 = scf.for ... iter_args(%arg1 = %c1, %arg2 = %c1) { ... } %x_epilogue:2 = scf.for ... iter_args(%arg1 = %x_unrolled#1, %arg2 = %x_unrolled#1) { ... } ```
show more ...
|
| #
1f23211c |
| 10-May-2022 |
Nicolas Vasilache <[email protected]> |
[mlir][SCF] Retire `cloneWithNewYields` helper function.
This is now subsumed by `replaceLoopWithNewYields`.
Differential Revision: https://reviews.llvm.org/D125309
|
| #
567fd523 |
| 06-May-2022 |
Mahesh Ravishankar <[email protected]> |
[mlir][SCF] Add utility method to add new yield values to a loop.
The current implementation of `cloneWithNewYields` has a few issues - It clones the loop body of the original loop to create a new
[mlir][SCF] Add utility method to add new yield values to a loop.
The current implementation of `cloneWithNewYields` has a few issues - It clones the loop body of the original loop to create a new loop. This is very expensive. - It performs `erase` operations which are incompatible when this method is called from within a pattern rewrite. All erases need to go through `PatternRewriter`.
To address these a new utility method `replaceLoopWithNewYields` is added which - moves the operations from the original loop into the new loop. - replaces all uses of the original loop with the corresponding results of the new loop - use a call back to allow caller to generate the new yield values. - the original loop is modified to just yield the basic block arguments corresponding to the iter_args of the loop. This represents a no-op loop. The loop itself is dead (since all its uses are replaced), but is not removed. The caller is expected to erase the op. Consequently, this method can be called from within a `matchAndRewrite` method of a `PatternRewriter`.
The `cloneWithNewYields` could be replaces with `replaceLoopWithNewYields`, but that seems to trigger a failure during walks, potentially due to the operations being moved. That is left as a TODO.
Differential Revision: https://reviews.llvm.org/D125147
show more ...
|
|
Revision tags: 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 |
|
| #
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 |
|
| #
dec8af70 |
| 31-Jan-2022 |
River Riddle <[email protected]> |
[mlir] Move SelectOp from Standard to Arithmetic
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.
Differenti
[mlir] Move SelectOp from Standard to Arithmetic
This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.
Differential Revision: https://reviews.llvm.org/D118648
show more ...
|
| #
f40475c7 |
| 27-Jan-2022 |
Adrian Kuegel <[email protected]> |
[mlir] Move SCF utils implementations to SCF/Utils.
BEGIN_PUBLIC [mlir] Move SCF utils implementations to SCF/Utils. END_PUBLIC
|