This is an archive of the discontinued LLVM Phabricator instance.

[mlir][vector] Add cast op between scalable and fixed-length vectors
AbandonedPublic

Authored by jsetoain on Jun 14 2022, 8:55 AM.

Details

Summary

This patch adds the vector.scalable_cast operation that allows
casting fixed-length vectors to scalable vectors and vice-versa.

This functionality is needed in order to interface VLS (vector length
specific) code with scalable functions and intrinsics.

This change has been discussed in:

https://discourse.llvm.org/t/rfc-interfacing-between-fixed-length-and-scalable-vectors-for-vls-vector-code-on-scalable-vector-architectures/63074

Diff Detail

Event Timeline

jsetoain created this revision.Jun 14 2022, 8:55 AM
jsetoain requested review of this revision.Jun 14 2022, 8:55 AM
zhanghb97 added inline comments.Jun 14 2022, 11:42 AM
mlir/include/mlir/Dialect/Vector/IR/VectorOps.td
2061

According to the discussion, from the syntax and semantic point of view, maybe we should allow a small vector to be inserted into a large one.
Take the invalid test case in this patch as an example:

%0 = vector.scalable_cast %vin : vector<8xf32> to vector<[16]xf32>

Although the size of the scalable vector depends on the target hardware, the vector<8xf32> should be smaller than vector<[16]xf32> in most cases, so this seems safe to use. Should we classify the cases like this as legal?

jsetoain added inline comments.Jun 14 2022, 2:33 PM
mlir/include/mlir/Dialect/Vector/IR/VectorOps.td
2061

Indeed. But you can already insert smaller vectors into larger ones for fixed-length vectors, so I can't see a real reason or advantage to having the ability to go directly from small fixed to large scalable. If you are casting between fixed-length and scalable length, you already know the size of the physical underlaying vector; you can use that and then cast. There's an example of that in my last comment to that thread. If I'm missing something, please let me know in the thread :-)

jsetoain abandoned this revision.Jun 15 2022, 3:01 AM

It is unclear to me why we want different semantics than LLVM.

vector.scalable_insert/extract

that work only on 1-D vectors seem less surprising.