This avoids accidentally reversing the order of constants during successive
application, e.g. when running the canonicalizer. This helps reduce the number
of iterations, and also avoids unnecessary changes to input IR.
Fixes #51892
Paths
| Differential D122692
[GreedPatternRewriter] Preprocess constants while building worklist when not processing top down ClosedPublic Authored by rriddle on Mar 29 2022, 4:28 PM.
Details Summary This avoids accidentally reversing the order of constants during successive Fixes #51892
Diff Detail
Event TimelineHerald added subscribers: stephenneuendorffer, nicolasvasilache, jdoerfert. · View Herald Transcript rriddle retitled this revision from [GreedPatternRewriteDriver] Preprocess constants when building the worklist to [GreedPatternRewrite] Preprocess constants while building worklist when not processing top down.Mar 29 2022, 4:30 PM Comment Actions Nice, this was a pain point for folks diff'ing across passes, thanks!
This revision is now accepted and ready to land.Mar 29 2022, 5:01 PM This revision was landed with ongoing or failed builds.Mar 31 2022, 12:12 PM Closed by commit rG59bbc7a0851b: [GreedPatternRewriter] Preprocess constants while building worklist when not… (authored by rriddle). · Explain Why This revision was automatically updated to reflect the committed changes. Comment Actions This change is causing some behaviour which I am struggling to describe. I'm trying to make a reproducer. No need to revert (I don't think). Comment Actions So there are at least 2 significant changes to behaviour
Comment Actions
Was this kind of awkwardly relying on the fact that we always did 2 iterations (given that we refolded existing constants)?
The situations where that happens feels kind of wrong. Folding a constant into a different constant feels weird.
Comment Actions
To expound upon this further, it feels like an implicit canonicalization on the foo.my_const. Comment Actions
And one of a or b were constant? Then isn't this expected to work? E.g., the constant operand is flipped before pattern matching is attempted?
Yeah this is unfortunate, but it meant that previously this was seen as canonical behavior. Not ideal I agree. @Mogball does this just affect unit test rather than semantics/end-to-end behavior? (The new behavior probably results in less changes compared to old - in particular there was the case of discardable attributes getting dropped from constants due to this). Comment Actions
Add few more contexts here. My understanding is, we changed the timing of adding a constant to the folder, The case we are seeing is a pattern like %cst = ... %bar = ... %foo = Foo(%cst, %bar) In the past, it will have two runs on the ir because it will add %cst to the folder and veiw it as a success folding. besides, In the first run, it also reorders the operands of FooOp. As a result, in the second round, the pattern can be matched. And now, the %cst has been added to the folder. When it calls tryToFold, it just returns failure(). So there's no second round (even the operands of FooOp has been reordered). And when we check the IR that failed to match, it shows %cst = ... %bar = ... %foo = Foo(%bar, %cst) Which make us think why it wasn't matched even the form looks correct.
Comment Actions
To me this is a breakage of the API contract of applyPatternsAndFoldGreedily: it does not seem right that applyPatternsAndFoldGreedily "converges" and returns while a pattern would still apply. Comment Actions
Agreed here. It seems to me that this has been an underlying issue masked by the way we were processing constants (i.e. unnecessarily refolding). Comment Actions
Talked to River offline: seems like a good reason to temporarily revert, he'll re-land with a fix.
Revision Contents
Diff 419010 flang/test/Lower/host-associated.f90
mlir/include/mlir/Transforms/FoldUtils.h
mlir/lib/Transforms/Utils/FoldUtils.cpp
mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp
mlir/test/Conversion/VectorToSCF/vector-to-scf.mlir
mlir/test/Dialect/Async/async-parallel-for-num-worker-threads.mlir
mlir/test/Dialect/Linalg/detensorize_if.mlir
mlir/test/Dialect/Linalg/transform-patterns.mlir
mlir/test/Dialect/SparseTensor/dense.mlir
mlir/test/Dialect/SparseTensor/sparse_scalars.mlir
mlir/test/Dialect/Tensor/bufferize.mlir
mlir/test/Dialect/Tensor/split-padding.mlir
mlir/test/Transforms/test-operation-folder.mlir
|
opportunity