[llvm-dev] RFC: Allowing scalable vectors in structs to support multiple return values from intrinsics

[Chris Lattner via llvm-dev]

On Jan 6, 2021, at 2:27 PM, Craig Topper via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi,
> 
> RISCV vector intrinsics have a need to return multiple scalable vector values. We plan to use this to return multiple results from segment load intrinsics. These instructions conceptually load multiple separate registers. I believe SVE has similar load intrinsics, but they use wide scalable vectors that get split during type legalization. We are struggling to do the same since we already use the size of the fixed part of a scalable vector to determine LMUL size. This means we have legal scalable vector types with different fixed part sizes. This makes it very difficult for type legalization to split a wide vector type for a segment load into the correct number of pieces. We feel that returning multiple results and avoiding the type legalizer is an easier path.
> 
> Unfortunately, supporting multiple scalable vectors being returned from an intrinsic requires scalable vectors to be allowed in structs. We would disallow such structs to be used by loads/stores/allocas/geps which would avoid needing to determine the offsets of any of the fields in the struct.
> 
> I've posted an initial patch for the IR and verifier portions of this here https://reviews.llvm.org/D94142 <https://reviews.llvm.org/D94142>
> 
> We would appreciate any feedback on this direction.

Ugh — I agree this is probably the least bad direction to go :-).

The real issue here is that LLVM IR doesn’t support multiple result values, instead forcing the use of first class aggregates.  Given that design decision (which I regret btw) I agree with you that we have to do something like this, since scalable vectors are registers.  Things shouldn’t be pinned into memory just because we get multiple results back.

I think that restricting this from “loaded and stored” FCA is a good way to go.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210106/fc4c7178/attachment-0001.html>