summaryrefslogtreecommitdiff
path: root/mlir/lib/Transforms/ControlFlowSink.cpp
AgeCommit message (Collapse)Author
2022-11-15[mlir] Remove `Transforms/SideEffectUtils.h` and move the methods into ↵Mahesh Ravishankar
`Interface/SideEffectInterfaces.h`. The methods in `SideEffectUtils.h` (and their implementations in `SideEffectUtils.cpp`) seem to have similar intent to methods already existing in `SideEffectInterfaces.h`. Move the decleration (and implementation) from `SideEffectUtils.h` (and `SideEffectUtils.cpp`) into `SideEffectInterfaces.h` (and `SideEffectInterface.cpp`). Also drop the `SideEffectInterface::hasNoEffect` method in favor of `mlir::isMemoryEffectFree` which actually recurses into the operation instead of just relying on the `hasRecursiveMemoryEffectTrait` exclusively. Differential Revision: https://reviews.llvm.org/D137857
2022-10-12Introduce a ConditionallySpeculatable op interfaceSanjoy Das
This patch takes the first step towards a more principled modeling of undefined behavior in MLIR as discussed in the following discourse threads: 1. https://discourse.llvm.org/t/semantics-modeling-undefined-behavior-and-side-effects/4812 2. https://discourse.llvm.org/t/rfc-mark-tensor-dim-and-memref-dim-as-side-effecting/65729 This patch in particular does the following: 1. Introduces a ConditionallySpeculatable OpInterface that dynamically determines whether an Operation can be speculated. 2. Re-defines `NoSideEffect` to allow undefined behavior, making it necessary but not sufficient for speculation. Also renames it to `NoMemoryEffect`. 3. Makes LICM respect the above semantics. 4. Changes all ops tagged with `NoSideEffect` today to additionally implement ConditionallySpeculatable and mark themselves as always speculatable. This combined trait is named `Pure`. This makes this change NFC. For out of tree dialects: 1. Replace `NoSideEffect` with `Pure` if the operation does not have any memory effects, undefined behavior or infinite loops. 2. Replace `NoSideEffect` with `NoSideEffect` otherwise. The next steps in this process are (I'm proposing to do these in upcoming patches): 1. Update operations like `tensor.dim`, `memref.dim`, `scf.for`, `affine.for` to implement a correct hook for `ConditionallySpeculatable`. I'm also happy to update ops in other dialects if the respective dialect owners would like to and can give me some pointers. 2. Update other passes that speculate operations to consult `ConditionallySpeculatable` in addition to `NoMemoryEffect`. I could not find any other than LICM on a quick skim, but I could have missed some. 3. Add some documentation / FAQs detailing the differences between side effects, undefined behavior, speculatabilty. Reviewed By: rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D135505
2022-08-31[MLIR] Update pass declarations to new autogenerated filesMichele Scuttari
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-08-30Revert "[MLIR] Update pass declarations to new autogenerated files"Michele Scuttari
This reverts commit 2be8af8f0e0780901213b6fd3013a5268ddc3359.
2022-08-30[MLIR] Update pass declarations to new autogenerated filesMichele Scuttari
The patch introduces the required changes to update the pass declarations and definitions to use the new autogenerated files and allow dropping the old infrastructure. Reviewed By: mehdi_amini, rriddle Differential Review: https://reviews.llvm.org/D132838
2022-04-16[mlir] Refactor LICM into a utilityMogball
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
2022-04-15Revert "[mlir] Refactor LICM into a utility"Stella Stamenova
This reverts commit 3131f808243abe3746280e016ab9459c14d9e53b. This commit broke the Windows mlir bot: https://lab.llvm.org/buildbot/#/builders/13/builds/19745
2022-04-15[mlir] Refactor LICM into a utilityMogball
LICM is refactored into a utility that is application on any region. The implementation is moved to Transform/Utils.
2022-04-07[mlir][NFC] Drop a few unnecessary includes from Pass.hRiver Riddle
2022-03-28[mlir][cf-sink] Accept a callback for sinking operationsMogball
(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
2022-01-24[mlir:Transforms] Move out the remaining non-dialect independent transforms ↵River Riddle
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
2022-01-24[mlir] NFC control-flow sink cleanupMogball
2022-01-24[mlir] Add a ControlFlowSink pass.Mogball
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