[Mlir-commits] [mlir] [MLIR][NVVM] Adds an explicit aligned boolean attribute to nvvm.barrier (PR #192203)

[llvmlistbot at llvm.org]

================
@@ -1179,16 +1183,20 @@ def NVVM_BarrierOp : NVVM_SingleResultIntrinsicOp<"barrier",
   let results = (outs Optional<I32>:$res);
 
   let hasVerifier = 1;
+  let hasCanonicalizeMethod = 1;
 
   let assemblyFormat =
       "(`id` `=` $barrierId^)? (`number_of_threads` `=` $numberOfThreads^)? "
+      "custom<Aligned>($aligned) "
----------------
xys-syx wrote:

Thanks @durga4github. I tried that first, but ran into a parser conflict.
```
error: custom op 'nvvm.barrier' expected attribute of type 'nvvm.reduction',
       but found attribute '{aligned = false}'
  nvvm.barrier {aligned = false}
```
The `assemblyFormat` has `attr-dict` after an optional reduction group:

    (qualified($reductionOp)^ $reductionPredicate)? (`->` type($res)^)? attr-dict

For `nvvm.barrier {aligned = false}`, the generated parser tries the optional reduction group first and calls `parseOptionalAttribute`, which greedily consumes `{aligned = false}` as a `DictionaryAttr` and then fails the type check against `BarrierReductionAttr.

An alternative is to reorder `attr-dict` before the reduction group, which does let attr-dict handle `aligned` cleanly for the barrier sync cases. However, when meeting with the `.red.*.count` variants, neither approach parses `nvvm.barrier number_of_threads = %n
#nvvm.reduction<and> %pred -> i32` (aligned=true): MLIR's SSA parser greedily consumes `%n #` looking for a result-number suffix and errors before the reduction
attribute is seen.

According to this situation, would you mind giving your suggestions on the solutions?


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