[Mlir-commits] [mlir] [mlir] Fix GPU_Launch op getPrivateAttributions function (PR #178369)

[llvmlistbot at llvm.org]

================
@@ -0,0 +1,13 @@
+// RUN: mlir-opt %s -test-ir-visitors | FileCheck %s
----------------
woruyu wrote:

Thanks for the suggestion — I tried to build a focused testcase, but I’m running into a structural issue because the verification and printing logic interact in a way that makes the “expected error” hard to isolate.

Right now the behavior is split across three places:

1) Region-arg count check:
```
   if (!getBody().empty()) {
     if (getBody().getNumArguments() <
         kNumConfigRegionAttributes + getNumWorkgroupAttributions())
       return emitOpError("unexpected number of region arguments");
   }
```

2) Attributions address space verification:
```
   if (failed(verifyAttributions(getOperation(), getWorkgroupAttributions(),
                                 GPUDialect::getWorkgroupAddressSpace())) ||
       failed(verifyAttributions(getOperation(), getPrivateAttributions(),
                                 GPUDialect::getPrivateAddressSpace())))
     return failure();
```

3) Printer path asserts the body is non-empty:
```
   KernelDim3 LaunchOp::getGridSize() {
     assert(!getBody().empty() && "LaunchOp body must not be empty.");
     auto args = getBody().getArguments();
     return KernelDim3{args[6], args[7], args[8]};
   }
```

For the testcase I currently have, the region is omitted, so `getBody().empty()` is true. That lets us reach the attributions verification in (2), but it also means we can’t safely print the op: the printer ends up calling `getGridSize()` and hits the assert in (3). So instead of producing a verifier diagnostic, the test crashes.

If I instead “fix” the IR by adding a region so `getBody().empty()` becomes false, we immediately hit (1) first due to the region argument count, and we never reach the attributions verification in (2). In other words, I can’t get a clean testcase that exercises (2) without either crashing in printing (empty body) or being rejected earlier by (1) (non-empty body but arg-count mismatch).

Passing `--mlir-print-op-generic` can avoid the printer path that asserts, but that feels like papering over the issue rather than a robust test strategy.

At this point I’m struggling to construct a “good” testcase that reliably triggers the attributions verification (2) without using `-test-ir-visitors`. If you have a recommended way to structure such a test (or a preferred place to add a diagnostic/guard so that printing can’t assert on invalid IR), I’m happy to follow that approach.

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