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

[Andrzej Warzyński]

banach-space wrote:

> > It's perhaps more correct to say that OOB tails, OOB start indices, etc. have implementation-defined behavior at the MLIR level.
> 
> This is how OOB semantics are defined today.

Not quite :) 

There's a difference between **OOB tails** and **OOB start indices**, right? And `Vector` docs aren't clear whether OOB loads means "OOB tails + OOB start indices" or _just_ "OOB tails". From [vector.load docs](https://mlir.llvm.org/docs/Dialects/Vector/#vectorload-vectorloadop):
> Support and implementation of out-of-bounds vector loads is target-specific. 

MemRef is more explicit (from [memref.load docs](https://mlir.llvm.org/docs/Dialects/MemRef/#memrefload-memrefloadop)):
> The indices must be in-bounds: 0 <= idx < dim_size.

Presumably, the X86 loads that you are referring to require masks, no?

>  It was defined like this to support architectures that can deal with OOB accesses, including plain x86.

 For SVE, we have "speculative" First-Faulting Loads, see e.g. 
 * https://developer.arm.com/documentation/102476/0101/SVE-architecture-fundamentals/SVE-architecture-features 

(under "Vector partitioning for software-managed speculation"). However, AFAIK, there's no hardware that implements those and I would refrain from modelling OOB accesses in the interim.

> Re inbounds/nneg, what's the current state of affairs in other MLIR dialects, including memref, ptr, affine, etc.?

We should review that, agreed. First, I'd like to clarify `vector.load` + `vector.store` semantics. If you have the bandwidth, I can create a GitHub issue to discuss this in detail.

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