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

[Philip Reames via llvm-dev]

On 1/7/21 10:40 AM, Reid Kleckner via llvm-dev wrote:
> I think your approach is probably the best, but I think it's worth 
> sketching out an alternative approach using token that wouldn't 
> require verifier changes.
>
> If you want to avoid verifier changes, the token type already gives 
> you what you want: it is opaque, cannot be loaded and stored or phid, 
> and can serve as a "value multiplexer". You could invent new 
> intrinsics to extract the values you need. The source of a token 
> cannot be obscured, so lowering can always look through a token 
> operand, find the source, and link up the correct SDValue in codegen. 
> The downside is that all this solution would be opaque to the 
> mid-level optimizers. They already understand insertvalue and 
> extractvalue. So, I don't think this is a good way to go, but it's 
> worth considering.
>
> I think, if we all agree that first class aggregates that can be 
> loaded, stored, and phi'd, were a historical design mistake, then your 
> original proposed solution is a step in the direction of removing FCA 
> support.
>
> I wonder if, in the future, it would be possible to auto-upgrade IR 
> that contains these FCA operations by splitting them into scalar 
> operations, and we could make the verifier reject all of these 
> undesired operations.
+1 to this goal.  Getting there might be tricky, and take a while, but 
definite +1 to the direction.
>
> On Wed, Jan 6, 2021 at 2:27 PM Craig Topper via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto: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
>
>     We would appreciate any feedback on this direction.
>
>     Thanks,
>     ~Craig
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210107/629a45a5/attachment-0001.html>