Revision tags: 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 |
|
#
8c258fda |
| 15-Mar-2023 |
Jakub Kuderski <kubak@google.com> |
[ADT][mlir][NFCI] Do not use non-const lvalue-refs with enumerate
Replace references to enumerate results with either result_pairs (reference wrapper type) or structured bindings. I did not use stru
[ADT][mlir][NFCI] Do not use non-const lvalue-refs with enumerate
Replace references to enumerate results with either result_pairs (reference wrapper type) or structured bindings. I did not use structured bindings everywhere as it wasn't clear to me it would improve readability.
This is in preparation to the switch to zip semantics which won't support non-const lvalue reference to elements: https://reviews.llvm.org/D144503.
I chose to use values instead of const lvalue-refs because MLIR is biased towards avoiding `const` local variables. This won't degrade performance because currently `result_pair` is cheap to copy (size_t + iterator), and in the future, the enumerator iterator dereference will return temporaries anyway.
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D146006
show more ...
|
Revision tags: 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, 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 |
|
#
fa26c7ff |
| 16-Apr-2022 |
Mogball <jeffniu22@gmail.com> |
[mlir] Refactor LICM into a utility
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
|
#
353f0a8e |
| 16-Apr-2022 |
Stella Stamenova <stilis@microsoft.com> |
Revert "[mlir] Refactor LICM into a utility"
This reverts commit 3131f808243abe3746280e016ab9459c14d9e53b.
This commit broke the Windows mlir bot: https://lab.llvm.org/buildbot/#/builders/13/builds
Revert "[mlir] Refactor LICM into a utility"
This reverts commit 3131f808243abe3746280e016ab9459c14d9e53b.
This commit broke the Windows mlir bot: https://lab.llvm.org/buildbot/#/builders/13/builds/19745
show more ...
|
#
3131f808 |
| 15-Apr-2022 |
Mogball <jeffniu22@gmail.com> |
[mlir] Refactor LICM into a utility
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
|
Revision tags: llvmorg-14.0.1 |
|
#
7a80912d |
| 04-Apr-2022 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for modernize-use-default-member-init in ControlFlowSinkUtils.cpp (NFC)
|
#
b73f1d2c |
| 25-Mar-2022 |
Mogball <jeffniu22@gmail.com> |
[mlir][cf-sink] Accept a callback for sinking operations
(This was a TODO from the initial patch).
The control-flow sink utility accepts a callback that is used to sink an operation into a region.
[mlir][cf-sink] Accept a callback for sinking operations
(This was a TODO from the initial patch).
The control-flow sink utility accepts a callback that is used to sink an operation into a region. The `moveIntoRegion` is called on the same operation and region that return true for `shouldMoveIntoRegion`. The callback must preserve the dominance of the operation within the region. In the default control-flow sink implementation, this is moving the operation to the start of the entry block.
Reviewed By: mehdi_amini
Differential Revision: https://reviews.llvm.org/D122445
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3 |
|
#
671e30a1 |
| 07-Mar-2022 |
Mehdi Amini <joker.eph@gmail.com> |
Apply clang-tidy fixes for modernize-use-default-member-init to MLIR (NFC)
|
Revision tags: llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
#
a70aa7bb |
| 21-Jan-2022 |
River Riddle <riddleriver@gmail.com> |
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilities
This has been a major TODO for a very long time, and is necessary for establishing a proper dialect-free dep
[mlir:Transforms] Move out the remaining non-dialect independent transforms and utilities
This has been a major TODO for a very long time, and is necessary for establishing a proper dialect-free dependency layering for the Transforms library. Code was moved to effectively two main locations:
* Affine/ There was quite a bit of affine dialect related code in Transforms/ do to historical reasons (of a time way into MLIR's past). The following headers were moved to: Transforms/LoopFusionUtils.h -> Dialect/Affine/LoopFusionUtils.h Transforms/LoopUtils.h -> Dialect/Affine/LoopUtils.h Transforms/Utils.h -> Dialect/Affine/Utils.h
The following transforms were also moved: AffineLoopFusion, AffinePipelineDataTransfer, LoopCoalescing
* SCF/ Only one SCF pass was in Transforms/ (likely accidentally placed here): ParallelLoopCollapsing The SCF specific utilities in LoopUtils have been moved to SCF/Utils.h
* Misc: mlir::moveLoopInvariantCode was also moved to LoopLikeInterface.h given that it is a simple utility defined in terms of LoopLikeOpInterface.
Differential Revision: https://reviews.llvm.org/D117848
show more ...
|
#
3628febc |
| 24-Jan-2022 |
Mogball <jeffniu22@gmail.com> |
[mlir] NFC control-flow sink cleanup
|
#
572fa964 |
| 24-Jan-2022 |
Mogball <jeffniu22@gmail.com> |
[mlir] Add a ControlFlowSink pass.
Control-Flow Sink moves operations whose only uses are in conditionally-executed regions into those regions so that paths in which their results are not needed do
[mlir] Add a ControlFlowSink pass.
Control-Flow Sink moves operations whose only uses are in conditionally-executed regions into those regions so that paths in which their results are not needed do not perform unnecessary computation.
Depends on D115087
Reviewed By: jpienaar, rriddle, bondhugula
Differential Revision: https://reviews.llvm.org/D115088
show more ...
|