llvm / llvm/llvm-project

[MLIR][Tensor] tensor.expand_shape with an empty reassociation group aborts mlir-opt

Open Beginner friendly
#222,602 1 comment 0 reactions 0 assignees View on GitHub
mlir
Dominant language
LLVM
Stars
40.5k
Forks
18.7k
PR merge metrics
PR metrics pending

Description

## Description

The tensor.expand_shape verifier reaches getSymbolLessAffineMaps with an empty reassociation group. The helper asserts on the empty group, causing mlir-opt to terminate with SIGABRT instead of returning a normal verifier diagnostic. The sibling tensor.collapse_shape verifier rejects the same malformed reassociation group normally.

## Steps to reproduce

Save the following as expand-empty-group.mlir:

```mlir
module {
func.func @expand_empty_group(%arg0: tensor<4xf32>) -> tensor<4xf32> {
%0 = tensor.expand_shape %arg0 [[]] output_shape [4] : tensor<4xf32> into tensor<4xf32>
return %0 : tensor<4xf32>
}
}
```

Run:

```bash
mlir-opt --verify-each expand-empty-group.mlir
```

## Expected behavior

The verifier should reject the invalid reassociation with a recoverable diagnostic, for example reassociation indices must not be empty. The process should remain alive and return a normal non-zero status.

## Actual behavior

With an assertions-enabled build, mlir-opt terminates with SIGABRT (shell exit status 134):

```text
mlir/lib/Dialect/Utils/ReshapeOpsUtils.cpp:454:
Assertion '!exprs.empty()' failed.
```

The stack trace reaches getSymbolLessAffineMaps and tensor::ExpandShapeOp::verify.

## Controls

A valid tensor.collapse_shape with reassociation [[0, 1]] is accepted. A tensor.collapse_shape with [[]] returns a normal verifier error. Element-count mismatch cases also return normal errors. A valid tensor.expand_shape with a non-empty reassociation is accepted.

## Environment

- LLVM/MLIR source revision: d8145e71418fb1e0a936adfb07dc5317113fc3b6
- Tool: mlir-opt from LLVM 23.1.0-rc2
- Build: optimized build with assertions enabled
- Platform: x86_64 Linux

The current upstream Tensor dialect implementation can be inspected in [TensorOps.cpp](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Tensor/IR/TensorOps.cpp). The shared helper is in [ReshapeOpsUtils.cpp](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Utils/ReshapeOpsUtils.cpp).

## Analysis

ExpandShapeOp::verify does not validate that every reassociation group is non-empty before requesting symbol-less affine maps. CollapseShapeOp::verify has a caller-side check for this condition, which explains the different behavior for the two sibling operations.

The closest related upstream issue is [LLVM MLIR #173567](https://github.com/llvm/llvm-project/issues/173567), fixed by [#173791](https://github.com/llvm/llvm-project/pull/173791). That fix adds the empty-group diagnostic to collapse_shape; it does not cover expand_shape. Element-count overflow issues [#221590](https://github.com/llvm/llvm-project/issues/221590) and [#222117](https://github.com/llvm/llvm-project/pull/222117) concern a different verifier condition.

## Impact

This is a compiler robustness issue: user-authored textual MLIR can terminate an assertion-enabled compiler process during verification. This reproducer does not demonstrate generated-code miscompilation, an out-of-bounds access, or a memory-safety violation.

## Suggested fix

Validate every reassociation group in ExpandShapeOp::verify before constructing symbol-less affine maps and emit an operation diagnostic for an empty group. Add a regression test covering the input above and verify that mlir-opt returns an error without aborting.

Contributor guide

Open the contributing guide

Research direction

Start in mlir/lib/Dialect/Tensor/IR/TensorOps.cpp at ExpandShapeOp::verify, comparing its reassociation checks with CollapseShapeOp::verify. Reproduce with expand-empty-group.mlir using mlir-opt --verify-each, then add a regression test showing that an empty group produces a normal verifier diagnostic and does not abort.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
compilers
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.