[Mlir-commits] [mlir] [mlir][GPU] Extend gpu.barrier with scope and named-barrier support (PR #195692)
Fabian Mora
llvmlistbot at llvm.org
Wed May 6 05:51:22 PDT 2026
================
@@ -1443,35 +1451,92 @@ def GPU_BarrierOp : GPU_Op<"barrier">,
accessing the same memory can be avoided by synchronizing work items
in-between these accesses.
- If the `memfence` attribute is specified, the set of memory accesses that must
- by completed after the barrier resolves is limited to only those accesses that
- read from or write to the specified address spaces (though accesses to other
- address spaces may be completed as well, especially if a particular combination
- of address spaces is not supported on a given backend). In particular,
- specifying `memfence []` creates a barrier that is not required to affect
- the visibility of any memory operations and is purely used for synchronizing
- work items.
+ The `scope` attribute controls the execution scope of the barrier:
```mlir
- // Only workgroup address spaces accesses required to be visible.
+ // Synchronize within a subgroup (warp/wavefront).
+ gpu.barrier scope <subgroup>
+ // Synchronize across the entire device.
+ gpu.barrier scope <device>
+ ```
+
+ A `named` barrier allows synchronizing a specific subset of subgroups
+ that have been associated with a named barrier handle. Named barriers
+ require workgroup scope.
----------------
fabianmcg wrote:
In view of https://developer.nvidia.com/blog/cooperative-groups/ the requirement of workgroup seems arbitrary.
https://github.com/llvm/llvm-project/pull/195692
More information about the Mlir-commits
mailing list