You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[mlir][linalg] Fix and Refactor DecomposeOuterUnitDimsUnPackOpPattern
This PR fixes an issue identified in llvm#118786, where the following
example triggers a verification error:
```mlir
func.func @foo(
%src: tensor<1x1x2x?xf32>,
%dest: tensor<5x1xf32>,
%tile_dim: index) -> tensor<5x1xf32> {
%0 = tensor.unpack %src
inner_dims_pos = [1, 0]
inner_tiles = [2, %tile_dim]
into %dest : tensor<1x1x2x?xf32> -> tensor<5x1xf32>
return %0 : tensor<5x1xf32>
}
```
The error occurs because of faulty logic when computing dynamic sizes
for `tensor::EmptyOp`, which initializes tensors for `linalg::transpose`.
This specific example fails due to:
* Dynamic inner tile size, combined with
* Non-identity permutation.
For reference, here's the verification error:
```bash
error: 'tensor.empty' op incorrect number of dynamic sizes, has 0, expected 1
```
and here's the problematic `tensor.empty` (printed in generic form):
```mlir
%1 = "tensor.empty"() : () -> tensor<?x2xf32>
```
**Fix**
This PR refactors how dynamic sizes for `tensor::EmptyOp` are computed. Instead
of generating a separate vector of dynamic sizes to complement the output
shape, this PR adopts a common MLIR idiom: passing a vector of `OpFoldResult`s
directly to the `EmptyOp` builder. Previously, only dynamic sizes corresponding
to outer dimensions were tracked (see `dynamicSizes`), while inner dimensions
were skipped, causing issues in certain cases.
**Refactoring changes**
Variable names have been updated for better readability:
* `readShape` → `readShapeForExtractSlice`
* `readSizes` → `extractSliceSizes`
* `readStrides` → `stridesForExtractSlice`
Additional comments have been added for clarity.
**Remaining inconsistencies**
Patterns for `tensor::PackOp` and `tensor::UnpackOp` remain partially inconsistent:
`DecomposeOuterUnitDimsPackOpPattern` enforces that all outer dimensions must be
unit-sized, while `DecomposeOuterUnitDimsUnPackOpPattern` does not. The two
implementations have diverged in logic. I plan to address these inconsistencies
in a follow-up PR to further unify these patterns.
0 commit comments