[Mlir-commits] [mlir] [mlir][vector] Add opt-in `inbounds`/`nneg` flags to `vector.load`/`vector.store` (PR #202118)

[Andrzej Warzyński]

banach-space wrote:

### Re inbounds / "remain in bounds at each step".

Thanks for checking!

> am I missing something?

No, I don't think so. I was worried about loads that read more than one SIMD-register worth of data, e.g. (for NEON):
```mlir
%0 = vector.load %src[%i0] : memref<?xf32>, vector<8xf32>
```

Loads like that need to be "decomposed", but that will happen in LLVM. We don't need to worry about it at the MLIR-LLVM boundary. All good!

> I'd add inbounds to vector.load as also suggested by @krzysz00.

I am against this change. 

Similarly to `in_bounds` in xfer Ops (which we pay next next to no attention in our transformations), such  attributes tend to become unhelpful noise - we have gradually transitioned to using masks instead (with small exceptions).

Instead, I suggest updating the docs similarly to what you've proposed for MemRef:

> A small docs PR will make the memref.load wording precise (an out-of-bounds index makes the getelementptr result a poison value, hence the immediate UB arises when the subsequent load/store dereferences that poison pointer).

This way, we will have consistency between MemRef and Vector and will also favour high-level solutions (like masks) in `Vector` instead of low-level concepts from LLVM.

### Re nuw

> > 1. I could've sworn we didn't allow negative strides in memref, so `nuw` and `inbounds` on `memref.load` is correct
> 
> Unfortunately, I think that this is not true, but please correct me if I'm wrong 🙏

> I think we might want to put up a docs patch explicitly clarifying if negative strides are allowed (I can't see anything forbidding them, but I don't have a good sense of the usecase, and stuff like vector.load is absolutely not set up to read "backwards" for statically negative strides). 

+1 for forbidding them, at least in the context of lowering to LLVM.

@krzysz00 , re this comment:
> Also, the OOB tail is LLVM-level UB, but, again, in graphics contexts or other such cases, you can absolutely have defined behavior for such a tail

Do people lower via LLVM in those contexts?

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