[Mlir-commits] [mlir] [mlir][linalg] Consolidate tests for scalable vectorization (PR #141469)

[Andrzej Warzyński]

================
@@ -36,6 +40,42 @@ module attributes {transform.with_named_sequence} {
 
 // -----
 
+func.func @vectorize_dynamic_identity_scalable(%arg0: tensor<?xf32>,
+                                               %arg1: tensor<?xf32>,
+                                               %arg2: tensor<?xf32>) -> tensor<?xf32> {
+  %0 = linalg.generic { indexing_maps = [affine_map<(d0) -> (d0)>,
+                                         affine_map<(d0) -> (d0)>,
+                                         affine_map<(d0) -> (d0)>],
+                   iterator_types = ["parallel"] }
+    ins(%arg0, %arg1 : tensor<?xf32>, tensor<?xf32>)
+    outs(%arg2 : tensor<?xf32>) {
+    ^bb(%in0: f32, %in1: f32, %out: f32) :
+      %0 = arith.addf %in0, %in1 : f32
+      linalg.yield %0 : f32
+    } -> tensor<?xf32>
+  return %0 : tensor<?xf32>
+}
+
+// CHECK-LABEL:   @vectorize_dynamic_identity_scalable
----------------
banach-space wrote:

> I was not going to bring up this topic, but I can share what I learned recently:
> https://mlir.llvm.org/getting_started/TestingGuide/#filecheck-best-practices

I  try to implement it in all my tests, but I am also discovering that:
* Some MLIR outputs are just inherently long and there is little that can be done about it (some examples here: https://github.com/llvm/llvm-project/blob/main/mlir/test/Dialect/ArmNeon/lower-to-arm-neon.mlir).
* `minimal set of functionalities` can be hard to identify if you are new to some area. Folks with more experience will know better what's e.g. "trivial and does not require checking".

That said, I totally agree we can and should do better - including me 😅 

> For some wide-lines checks, e.g., masking, we may break them into a couple of lines using CHECK-SAME trick, IMO.

Yes, I really like this idea!

> I think we don't really care what the type is for C1_IDX and DIM_A0_1

We usually don't. However, in many cases the only option is to either add the type (which caries useful info) or some arbitrary index. Basically:
```mlir
// With type info:
// CHECK:    %[[C0_IDX:.*]] = arith.constant 0 : index
(...)
// CHECK:    %[[C0_f32:.*]] = arith.constant 0.000000e+00 : f32
```
vs:
```mlir
// With an index:
// CHECK:    %[[C0_0:.*]] = arith.constant 0 : index
(...)
// CHECK:    %[[C0_1:.*]] = arith.constant 0.000000e+00 : f32
```

🤷🏻 In practice, I find that `%[[C0_1:.*]] = arith.constant 0.000000e+00 : f32` usually represents the padding value, so `%[[PAD:.*]] = arith.constant 0.000000e+00 : f32` often works. 

That's quite a tangent here 😅 😂 

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