Reid Kleckner via llvm-dev
2021-Jan-07 18:40 UTC
[llvm-dev] RFC: Allowing scalable vectors in structs to support multiple return values from intrinsics
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. On Wed, 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 > > We would appreciate any feedback on this direction. > > Thanks, > ~Craig > _______________________________________________ > 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/cbcfd4f9/attachment.html>
Philip Reames via llvm-dev
2021-Jan-08 01:26 UTC
[llvm-dev] RFC: Allowing scalable vectors in structs to support multiple return values from intrinsics
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>