[Mlir-commits] [mlir] [MLIR] Implement emulation of static indexing subbyte type vector stores (PR #115922)

[Andrzej Warzyński]

================
@@ -0,0 +1,104 @@
+// RUN: mlir-opt --test-emulate-narrow-int="arith-compute-bitwidth=1 memref-load-bitwidth=8 atomic-store=false" --cse --split-input-file %s | FileCheck %s
+
+// TODO: remove memref.alloc() in the tests to eliminate noises.
+// memref.alloc exists here because sub-byte vector data types such as i2
+// are currently not supported as input arguments.
+
+func.func @vector_store_i2_const_rmw(%arg0: vector<3xi2>) {
+    %0 = memref.alloc() : memref<3x3xi2>
+    %c0 = arith.constant 0 : index
+    %c2 = arith.constant 2 : index
+    vector.store %arg0, %0[%c2, %c0] :memref<3x3xi2>, vector<3xi2>
+    return
+}
----------------
banach-space wrote:

> The const means it is testing const indices, which can be statically folded.

But the actual function is identical to `@vector_store_i2_atomic`? I would prioritise consistency and keep function names identical. In particular, in this case, the `_rmw` suffix 
* **does not describe** the input (it should encode the unique features of the _input_),
* **describes** the transformation that will be applied to the input (for that you'd use the file name or FileCheck's [--check-prefix](https://llvm.org/docs/CommandGuide/FileCheck.html#cmdoption-FileCheck-check-prefix) instead). 

In fact, you are only changing the pass that you are exercising, but not the input. I think that we/you should consider moving the input to one file and then leveraging FileCheck's [--check-prefix](https://llvm.org/docs/CommandGuide/FileCheck.html#cmdoption-FileCheck-check-prefix). This way, the comparison between `atomic-store=false` and `atomic-store=true` would be much easier/clearer.

For example, instead of (split by `atomic-store`):
* vector-emulate-narrow-type-unaligned.mlir, and
* vector-emulate-narrow-type-unaligned-rmw.mlir,

create (split by Operation type):
* vector-store-emulate-narrow-type-store-unaligned.mlir, and
* vector-store-emulate-narrow-type-load-unaligned-rmw.mlir,
* ...

Perhaps there's some more future-proof approach 🤔 

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