[Mlir-commits] [mlir] [mlir][linalg] Support subtracting accumulation in partial reduction … (PR #214033)

[llvmlistbot at llvm.org]

================
@@ -1029,3 +1029,104 @@ module attributes {transform.with_named_sequence} {
 //       CHECK:   }
 //       CHECK:   linalg.reduce ins(%[[L]] : tensor<?x3x?x4xf32>) outs(%arg1 : tensor<?x3x?xf32>) dimensions = [3]
 //       CHECK:   return %{{.*}}
+
+// -----
+
+// A subtracting accumulation (`acc - x`) reduces the negated inputs. It is
+// tiled starting from the additive neutral element, and its partial results are
+// merged with an addition rather than with the subtraction itself.
+
+func.func @reduction_tile_negated_sum(%arg0: tensor<?x?xf32>, %out: tensor<?xf32>) -> tensor<?xf32> {
+  %red = linalg.generic {indexing_maps = [affine_map<(d0, d1) -> (d0, d1)>,
+                                          affine_map<(d0, d1) -> (d0)>],
+   iterator_types = ["parallel", "reduction"]}
+   ins(%arg0 : tensor<?x?xf32>)
+   outs(%out : tensor<?xf32>) {
+    ^bb0(%arg7: f32, %arg9: f32):
+      %1 = arith.subf %arg9, %arg7 : f32
+      linalg.yield %1 : f32
+    } -> tensor<?xf32>
+  return %red : tensor<?xf32>
+}
+
+module attributes {transform.with_named_sequence} {
+  transform.named_sequence @__transform_main(%arg1: !transform.any_op {transform.readonly}) {
+    %0 = transform.structured.match ops{["linalg.generic"]} in %arg1 : (!transform.any_op) -> !transform.any_op
+    %1, %2, %3, %loop = transform.structured.tile_reduction_using_for %0
+      by tile_sizes = [0, 5] : (!transform.any_op) -> (!transform.any_op, !transform.any_op, !transform.any_op, !transform.any_op)
+      transform.yield
+  }
+}
+
+// CHECK-LABEL: func @reduction_tile_negated_sum
+//   CHECK-DAG:   %[[I:.*]] = arith.constant 0.000000e+00 : f32
+//       CHECK:   %[[F:.*]] = linalg.fill ins(%[[I]] : f32) outs(%{{.*}} : tensor<?x5xf32>) -> tensor<?x5xf32>
+//       CHECK:   %[[L:.*]] = scf.for {{.*}} iter_args(%{{.*}} = %[[F]]) -> (tensor<?x5xf32>) {
+//       CHECK:     linalg.generic
+//       CHECK:       arith.subf
----------------
pstarkcdpr wrote:

Definitely. The `subf` wasn't checking the order of operands here, which is part of the issue being solved. Addressed in 1c20a0efdce3b28f74f8c14768429f77274a185a

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