|
Revision tags: 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 |
|
| #
36a40551 |
| 14-Oct-2024 |
Sasha Lopoukhine <superlopuh@gmail.com> |
[mlir][SCF] Multiply lower bound in loop range folding (#111875)
Fixes #83482
|
|
Revision tags: 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 |
|
| #
13bd4109 |
| 18-Oct-2022 |
rkayaith <rkayaith@gmail.com> |
[mlir][Pass] Include anchor op in -pass-pipeline
In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the `-pass-
[mlir][Pass] Include anchor op in -pass-pipeline
In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the `-pass-pipeline` argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to `-pass-pipeline`. In most cases this requires updating `-pass-pipeline='pipeline'` to `-pass-pipeline='builtin.module(pipeline)'`.
This also fixes an outdated assert that prevented running a `PassManager` anchored on `'any'`.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D134900
show more ...
|
|
Revision tags: llvmorg-15.0.3, working, 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, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
0254b0bc |
| 20-Apr-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir][NFC] Update textual references of `func` to `func.func` in LLVM/Math/MemRef/NVGPU/OpenACC/OpenMP/Quant/SCF/Shape tests
The special case parsing of `func` operations is being removed.
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
| #
36550692 |
| 08-Mar-2022 |
River Riddle <riddleriver@gmail.com> |
[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 ...
|
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
92ccb8cc |
| 30-Jan-2022 |
Uday Bondhugula <uday@polymagelabs.com> |
[MLIR][NFC] Update SCF pass cmd line names to prefix scf
Update SCF pass cmd line names to prefix `scf`. This is consistent with guidelines/convention on how to name dialect passes. This also avoids
[MLIR][NFC] Update SCF pass cmd line names to prefix scf
Update SCF pass cmd line names to prefix `scf`. This is consistent with guidelines/convention on how to name dialect passes. This also avoids ambiguity on the context given the multiple `for` operations in the tree.
NFC.
Differential Revision: https://reviews.llvm.org/D118564
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
a54f4eae |
| 12-Oct-2021 |
Mogball <jeffniu22@gmail.com> |
[MLIR] Replace std ops with arith dialect ops
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects.
Renamed
[MLIR] Replace std ops with arith dialect ops
Precursor: https://reviews.llvm.org/D110200
Removed redundant ops from the standard dialect that were moved to the `arith` or `math` dialects.
Renamed all instances of operations in the codebase and in tests.
Reviewed By: rriddle, jpienaar
Differential Revision: https://reviews.llvm.org/D110797
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1 |
|
| #
f8479d9d |
| 28-Jul-2021 |
River Riddle <riddleriver@gmail.com> |
[mlir] Set the namespace of the BuiltinDialect to 'builtin'
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities
[mlir] Set the namespace of the BuiltinDialect to 'builtin'
Historically the builtin dialect has had an empty namespace. This has unfortunately created a very awkward situation, where many utilities either have to special case the empty namespace, or just don't work at all right now. This revision adds a namespace to the builtin dialect, and starts to cleanup some of the utilities to no longer handle empty namespaces. For now, the assembly form of builtin operations does not require the `builtin.` prefix. (This should likely be re-evaluated though)
Differential Revision: https://reviews.llvm.org/D105149
show more ...
|
|
Revision tags: llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
| #
3f429e82 |
| 24-Jun-2021 |
Anthony Canino <anthony.canino1@gmail.com> |
Implement an scf.for range folding optimization pass.
In cases where arithmetic (addi/muli) ops are performed on an scf.for loops induction variable with a single use, we can fold those ops directly
Implement an scf.for range folding optimization pass.
In cases where arithmetic (addi/muli) ops are performed on an scf.for loops induction variable with a single use, we can fold those ops directly into the scf.for loop.
For example, in the following code:
``` scf.for %i = %c0 to %arg1 step %c1 { %0 = addi %arg2, %i : index %1 = muli %0, %c4 : index %2 = memref.load %arg0[%1] : memref<?xi32> %3 = muli %2, %2 : i32 memref.store %3, %arg0[%1] : memref<?xi32> } ```
we can lift `%0` up into the scf.for loop range, as it is the only user of %i:
``` %lb = addi %arg2, %c0 : index %ub = addi %arg2, %i : index scf.for %i = %lb to %ub step %c1 { %1 = muli %0, %c4 : index %2 = memref.load %arg0[%1] : memref<?xi32> %3 = muli %2, %2 : i32 memref.store %3, %arg0[%1] : memref<?xi32> } ```
Reviewed By: mehdi_amini, ftynse, Anthony
Differential Revision: https://reviews.llvm.org/D104289
show more ...
|