[Mlir-commits] [mlir] [mlir][vector][nfc] Add tests + update docs for narrow-type emulation (PR #115460)

[Andrzej Warzyński]

banach-space wrote:

> @dcaballe @banach-space the preceding zeros will be used when a memref's innermost dim is not strictly byte aligned.

Thank you for explaining; that makes sense! I’ll restore the original logic in the comment. This only occurs in cases with sub-byte types, correct? It’d be helpful to call that out explicitly.

Also, considering the definitions of [vector.constant_mask](https://mlir.llvm.org/docs/Dialects/Vector/#vectorconstant_mask-vectorconstantmaskop) and [vector.create_mask](https://mlir.llvm.org/docs/Dialects/Vector/#vectorcreate_mask-vectorcreatemaskop), how would we construct the corresponding mask? I assume it would be created via `arith.constant`, something like this:
```mlir
func.func @vector_maskedload_i4_constant_mask(%passthru: vector<8xi4>) -> vector<8xi4> {
  %0 = memref.alloc() : memref<3x8xi4>
  %cst = arith.constant dense<0> : vector<8xi4>
  %mask = arith.constant dense<[false, true, true, true, true, false, false, false]> : vector<8xi1>
  %c0 = arith.constant 0 : index
  %1 = vector.maskedload %0[%c0, %c0], %mask, %passthru :
    memref<3x8xi4>, vector<8xi1>, vector<8xi4> into vector<8xi4>
  return %1 : vector<8xi4>
}
```

This example demonstrates the scenario described in the comment and could also help clarify expected behavior. Unfortunately, it doesn’t work as expected:

* https://github.com/llvm/llvm-project/issues/115742

This suggests that while the sub-byte alignment case is theoretically possible, it’s likely that no one is actively relying on it, given that it’s currently broken.

Since everyone is stretched thin, I’d propose proactively disabling and documenting these broken paths to prevent confusion or missteps down the road. Hence e.g.:
* https://github.com/llvm/llvm-project/pull/115612

Just to clarify, I merely want to improve the overall health of this area. And, a bit selfishly, to make reviewing easier :) Like I said [elsewhere](https://github.com/llvm/llvm-project/pull/115070#discussion_r1835731246), your contributions in this area @lialan are much appreciated!

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