[Mlir-commits] [mlir] [mlir][vector][memref] Add `alignment` attribute to memory access ops (PR #144344)

[Oleksandr Alex Zinenko]

ftynse wrote:

> Currently, the lowerings of vector.load and vector.store to LLVM always assume that the pointer is aligned to the natural alignment of the vector element, not the vector. This is behavior users often want to override, either in general or on a case-by-case basis, and having an alignment attribute lets people do that

There's a lot of logic duplication as well as underdefined cases in this area that I'd love to see cleaned up. For example, we could cast a scalar memref to `memref<... x vector<>>`, at which point it becomes to load with the alignment of vector. Except we don't really have alignment well-specified for multidimensional vectors. And the `vector.load/store` don't preclude non-contiguous leading dimensions...

Again, my concern here is we keep adding alternative ways to do things thus increasing overall complexity of the system. These new ways may be more flexible or general than existing mechanisms, but we _must_ clean those up and ensure some overall coherence.

> I think this'll be a good moment to clarify what alignment means for sub-byte types, since we have EmulateNarrowTypes. I'd argue that if the type in the memref has width < 8 bits, then alignment should be in units of the number of elements, not the number of bytes. That'll allow the narrow type emulator to use faster lowerings when you, for example, do a vector.store %v, %m[[...], {alignment = 2 : index} : vector<2xi4>, memref<...xi4>

Please bring this to discourse. 

IMO, we could say alignment is always specified in the number of bits, not bytes, and be done with it. Having contextual rules to interpret an attribute is a ridiculous amount of unnecessary complexity.

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