[Mlir-commits] [mlir] [mlir][vector][spirv] Lower vector.transfer_read and vector.transfer_write to SPIR-V (PR #69708)

Lei Zhang llvmlistbot at llvm.org
Sun Nov 5 09:23:46 PST 2023


antiagainst wrote:

> There is a description in the document. That is, "A vector.transfer_read can be lowered to a simple load if all dimensions are specified to be within bounds and no mask was specified". Under these conditions, does it make sense to convert transfer_read/transfer_write to SPIR-V directly? I have not tried the way to convert transfer_read to memref.load though.

Yup. That "simple load" is modelled as `vector.load` or `memref.load` at a lower level. Keep in mind that the core concept behing mlir is to have suitable representations at the proper level so we can have a principled lowering flow and sharing common utilities--where we already build quite some pieces that you might find valuable in your flow. For example, the lowering for vector transfer ops to lower level already exists in [LowerVectorTransfer.cpp](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Vector/Transforms/LowerVectorTransfer.cpp); and we have stuff like [emulating narrow type](https://github.com/llvm/llvm-project/blob/main/mlir/lib/Dialect/Vector/Transforms/VectorEmulateNarrowType.cpp) for those lower level load ops like @kuar mentioned.

Right now we are missing vector.load/store to spirv lowering. For the cases you want to cover, I think it's worth adding them instead, which is much simpler (as we don't need to verify all those out of bounds, padding, indexing map, etc.).

There might be a place where we want to introduce vector transfer ops to spirv directly--for actually powerful cases not representable by vector.load/store and memref.load/store, _but_ we have direct hardware support that sort of exposed by spirv ops. That is a sign of maybe we want to discuss the representation at vector/memref load/store level; and that can take time. In the meanwhile it makes sense to connect directly there to keep things going.

Hopefully this explains the rationale. Again, thanks for the contribution! :)

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


More information about the Mlir-commits mailing list