[PATCH] D98169: [IR] Permit load/store/alloca for struct with the same scalable vectors.

[Sander de Smalen via Phabricator via llvm-commits]

sdesmalen added a comment.

Hi @HsiangKai, this is not a supported use-case for scalable vectors and it is explicitly called out in the LangRef:

> Scalable vectors cannot be global variables or members of arrays because their size is unknown at compile time. They are allowed in structs to facilitate intrinsics returning multiple values. Structs containing scalable vectors cannot be used in loads, stores, allocas, or GEPs.

There have been a few conversations about this before. I previously left a comment on D94142 <https://reviews.llvm.org/D94142> and there was also some discussion on @craig.topper's RFC to add limited support for intrinsics, which can be found here: https://lists.llvm.org/pipermail/llvm-dev/2021-January/147639.html

Supporting scalable vector types as exclusive members of structs that can be used in loads/stores/allocas is a bit of a sliding scale, because the next question will be the one @frasercrmck is asking: "Why can't you mix fixed/scalable types?".

It's been still relatively recent that we've settled on a definition for TypeSize which still needs to be supported in many places in the code-base. Mixing fixed/scalable adds another dimension of complexity, because then all interfaces that take an offset also need to consider the fact that it may be comprised of a fixed-width and scalable-width component. Also, at the moment there isn't really a use-case, there are no languages that allow or support structs/aggregates with scalable members.  The original advice given for "What if C/C++ allowed such a use case?" was to solve this in Clang, so as to remove the need for such support in LLVM IR.

The only reason we wanted to allow the use-case for return-values/operands of intrinsics is so that we can model operations that return multiple values which can be scalable, such as first-faulting loads where it returns a data vector (the loaded data) and a predicate mask for the lanes that faulted.

@HsiangKai was there a specific use-case that you had in mind for this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98169/new/

https://reviews.llvm.org/D98169