[Mlir-commits] [mlir] [mlir][VectorToLLVM] add opt-in `enable-gep-inbounds-nuw` pass flag for `vector.load/store` (PR #202118)

[Andrzej Warzyński]

================
@@ -345,6 +345,18 @@ def AffineScalarReplacement : Pass<"affine-scalrep", "func::FuncOp"> {
 
 def AffineVectorize : Pass<"affine-super-vectorize", "func::FuncOp"> {
   let summary = "Vectorize to a target independent n-D vector abstraction";
+  let description = [{
+    Vectorizes affine loops into `vector.transfer_read` / `vector.transfer_write`
+    operations. When an access is provably within bounds (all loop bounds are
+    statically known and the access pattern fits the memref), the generated
+    transfer ops carry `in_bounds = [true, ...]`, asserting that no
+    out-of-bounds masking is needed.
+
+    When this pass is combined with `ConvertVectorToLLVM` and its
+    `enable-gep-inbounds-nuw` option is set, the lowering of those
+    `vector.load` / `vector.store` ops (produced by lowering the
+    in-bounds transfers) emits `llvm.getelementptr inbounds|nuw`.
+  }];
----------------
banach-space wrote:

This PR updates `ConvertVectorToLLVM` rather than `SuperVectorize`. Updating the docs of passes that _could be used_ in one pipeline with `ConvertVectorToLLVM` is out-of-scope.

Also,:
* Presumably `SuperVectorize` generates other vector Ops as well? Why call out `transfer_read/transfer_write` specifically? What about the other Ops?
* `enable-gep-inbounds-nuw` is a fine detail of `ConvertVectorToLLVM` and this information is just noise for user of `SuperVectorize` that are not interested in using `ConvertVectorToLLVM`.

If you do want update the docs for `SuperVectorize`, I suggest a dedicated PR. But even then, I'd keep it more general than this (so that it applies to multiple users).

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