[Mlir-commits] [mlir] [mlir] Fix ComposeExpandOfCollapseOp for dynamic case (PR #142663)

Ian Wood llvmlistbot at llvm.org
Thu Jun 5 09:11:00 PDT 2025


================
@@ -387,11 +387,13 @@ struct ComposeExpandOfCollapseOp : public OpRewritePattern<ExpandOpTy> {
       auto resultSubShape =
           resultShape.slice(resultIndices.front(), resultIndices.size());
 
+      if (llvm::count_if(srcSubShape, ShapedType::isDynamic) >= 2)
+        return std::nullopt;
----------------
IanWood1 wrote:

Assuming the reassociation is

```
collapse: [[0, 1], [2], [3, 4, 5]]
expand: [[0], [1], [2, 3]]
```

The "subshape" reshape is `?x? -> ? -> ?` which is a trivial collapse but the check I added will skip it. Maybe both source and dst have to have >=2 dyn dims?

------


>Thinking out loud, but if there's more edge cases like this, maybe the correct way forward (on this affine map-ignoring path that we dislike) would be join the algorithms here and in getReassociationIndicesForCollapse(), so that we're always dealing with full information.

I think `findCollapsingReassociation` (this PR) and `getReassociationIndicesForCollapse` are answering different questions:

- `findCollapsingReassociation`: can this arbitrary reshape be simplified to a collapse?
- `getReassociationIndicesForCollapse`: given a source/target shape that is known to be a collapse, what is the reassociation?

The idea is that `findCollapsingReassociation` must determine that the reshape is representable as a collapse before using `getReassociationIndicesForCollapse`.

Using the example from the previous PR, `getReassociationIndicesForCollapse(?x8x128x? -> ?x128x?)` is `[[0, 1], [2]]` because you know the reshape is a collapse. But because `?x8x128x? -> ? -> ?x128x?` collapses into a single dimension you don't know that the output dynamic dimensions have any relation to the input dynamic dimensions (except for the product is 8x greater). At runtime it could be `10x8x128x10 -> 102400 -> 1x128x800` and there is no way to collapse `10x8x128x10` into `1x128x800`

https://github.com/llvm/llvm-project/pull/142663


More information about the Mlir-commits mailing list