| Issue |
61442
|
| Summary |
[MLIR] bad CHECKs generated with `generate-test-checks.py`
|
| Labels |
mlir
|
| Assignees |
|
| Reporter |
bmahjour
|
```
> cat tmp.mlir
module {
func.func @test1() {
%5 = dialect.op {
value=0
}
%6 = dialect.use %5
}
func.func @test2() {
%5 = dialect.op { value=0 }
%6 = dialect.use %5
}
func.func @test3() {
%5 = dialect.op
{
value=0
}
%6 = dialect.use %5
}
}
> cat tmp.mlir | ~/workspaces/llvm-project/mlir/utils/generate-test-checks.py
// NOTE: Assertions have been autogenerated by utils/generate-test-checks.py
// The script is designed to make adding checks to
// a test case fast, it is *not* designed to be authoritative
// about what constitutes a good test! The CHECK should be
// minimized and named to reflect the test intent.
// CHECK-LABEL: func.func @test1() {
// CHECK: %[[VAL_0:.*]] = dialect.op {
// CHECK: value=0
// CHECK: }
// CHECK: %[[VAL_1:.*]] = dialect.use %[[VAL_2:.*]]
// CHECK: }
// CHECK-LABEL: func.func @test2() {
// CHECK: %[[VAL_0:.*]] = dialect.op { value=0 }
// CHECK: %[[VAL_1:.*]] = dialect.use %[[VAL_0]]
// CHECK: }
// CHECK-LABEL: func.func @test3() {
// CHECK: %[[VAL_0:.*]] = dialect.op
// CHECK: {
// CHECK: value=0
// CHECK: }
// CHECK: %[[VAL_1:.*]] = dialect.use %[[VAL_0]]
// CHECK: }
```
In `test1`, instead of matching the value produced by `dialect.op` (ie. `VAL_0`), a new regexp variable (ie `VAL_2`) is introduced. This could cause false passes even if the result of the first op is not used as the operand of `dialect.use`.
Notice `test2` and `test3` are fine, so the issue seems to be related to SSA values produced by an operation with a line break after '{'.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
