[Mlir-commits] [mlir] [mlir][gpu] Add `gpu.subgroup_uniform` op (PR #157743)

[Mehdi Amini]

================
@@ -3255,4 +3255,37 @@ def GPU_SubgroupBroadcastOp : GPU_Op<"subgroup_broadcast",
   let hasVerifier = 1;
 }
 
+def GPU_SubgroupUniformOp : GPU_Op<"subgroup_uniform",
+    [Pure, AllTypesMatch<["result", "src"]>,
+    DeclareOpInterfaceMethods<InferIntRangeInterface, ["inferResultRanges"]>] #
+    ElementwiseMappable.traits>,
+  Arguments<(ins AnyType:$src)> {
+  let summary = "Assumes value is unform across the lanes in subgroup";
+  let description = [{
+    The "subgroup_uniform" op assumes that the value is uniform across all lanes
+    in a subgroup. This means that all active lanes in the subgroup are expected
+    to have the same value.
+
+    This op can be used to inform the compiler that a value is uniform across
+    the subgroup, enabling optimizations. The result is poison if the value
+    is not actually uniform.
+
+    This op is functionally no-op as no valid program should change its
+    semantics if this op is removed. Backends can choose to ignore it or do
+    some optimizations (e.g. put value into scalar registers).
+
+    This op can be freely speculated across structured control flow as parent
+    active mask is always superset of current mask and if can hoist input
+    calculation you can hoist the operation itself as well.
+
+    Example:
+
+    ```mlir
+    %1 = gpu.subgroup_uniform %0 : f32
+    ```
+  }];
+  let results = (outs AnyType:$result);
+  let assemblyFormat = "$src attr-dict `:` type($result)";
+}
----------------
joker-eph wrote:

> No, but the fact we can't think of one doesn't imply we can have unspecified semantics

Seems to me that you're trying to see something "unspecified" for case that would just violate SSA: a value is immutable and does not change based on which region it is used.
The speculation is only invalid if there was immediate UB, which isn't the case: the op is specified with a poison value on violation.

> then an analysis should be able to draw conclusions for %v0 based on %u0.

I believe this is mixing up the value with the user of the value. These assumes are inserted in the dataflow to insert assumption that the user know are valid only on some dataflow path. At least at this level of abstraction you can't reason across it the way you'd like to.

> I still think it should be acceptable to have as an invariant of an op requiring that an operand has a single use.

It's not: looking at the uses **is** a traversal of the SSA def-use chain and a non-local effect, seems clearly against the guideline.

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