Eric Christopher via llvm-dev
2019-Mar-18 17:39 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 3/15/19 10:58 AM, David Greene wrote: >> > Renato Golin <rengolin at gmail.com> writes: >> > >> >> On Fri, 15 Mar 2019 at 15:30, Finkel, Hal J. via llvm-dev >> >> <llvm-dev at lists.llvm.org> wrote: >> >>> I've talked with a number of people about this as well, and I think that >> >>> I understand the objections. I'm happy that ARM followed through with >> >>> the alternate set of patches. Regardless, however, unless those who had >> >>> wished to object still wish to object, and then actually do so, we now >> >>> clearly have a good collection of contributors actively desiring to do >> >>> code review, and we should move forward (i.e., start committing patches >> >>> once they're judged ready). >> >> Let's start by closing the three flying revisions, so that people that >> >> weren't involved in the discussion don't waste time looking at them. >> > See the reply I just posted to Hal. I am not sure we've made a decision >> > to abandon the current patches. We may in fact decide that, but I >> > haven't seen consensus for doing so yet. In fact I've seen the opposite >> > -- that people want to move forward with the scalable types. >> >> >> I agree with David. We should move forward with native support for >> scalable types. > > > Sorry I haven't been as available as usual for the past few weeks, but FWIW, I still am unconvinced that scalable vector types belong in the IR. > > I think this adds complexity to LLVM's IR to serve a niche use case without proven benefit to a broad spectrum of hardware or software. I think the complexity is significant and will be a net drag on all parts of the IR and IR-level transformations. But I don't really think it is useful to re-hash all these debates. Nothing relevant has changed in the years this has been discussed. > > That said, if I'm the only one who feels this way (and is willing to actually state this publicly), I'm not going to stop progress. >You're not, and I'm in the same position here. I don't think there's a really good answer for how this is going to affect a lot of the IR and IR-level transformations from a maintainability perspective. It mostly seems like this is a "we need this for the new ISA support" and while I don't see a lot of compelling use case here and a lot of downside that there... -eric
Bruce Hoult via llvm-dev
2019-Mar-19 00:26 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
Three ISAs at present: - SVE in Aarch64 - MVE in ARM Cortex-M (quite different from SVE) - RVV in RISC-V It would not surprise me if other ISAs implement similar vector extensions in future. On Mon, Mar 18, 2019 at 10:40 AM Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> > >> On 3/15/19 10:58 AM, David Greene wrote: > >> > Renato Golin <rengolin at gmail.com> writes: > >> > > >> >> On Fri, 15 Mar 2019 at 15:30, Finkel, Hal J. via llvm-dev > >> >> <llvm-dev at lists.llvm.org> wrote: > >> >>> I've talked with a number of people about this as well, and I think that > >> >>> I understand the objections. I'm happy that ARM followed through with > >> >>> the alternate set of patches. Regardless, however, unless those who had > >> >>> wished to object still wish to object, and then actually do so, we now > >> >>> clearly have a good collection of contributors actively desiring to do > >> >>> code review, and we should move forward (i.e., start committing patches > >> >>> once they're judged ready). > >> >> Let's start by closing the three flying revisions, so that people that > >> >> weren't involved in the discussion don't waste time looking at them. > >> > See the reply I just posted to Hal. I am not sure we've made a decision > >> > to abandon the current patches. We may in fact decide that, but I > >> > haven't seen consensus for doing so yet. In fact I've seen the opposite > >> > -- that people want to move forward with the scalable types. > >> > >> > >> I agree with David. We should move forward with native support for > >> scalable types. > > > > > > Sorry I haven't been as available as usual for the past few weeks, but FWIW, I still am unconvinced that scalable vector types belong in the IR. > > > > I think this adds complexity to LLVM's IR to serve a niche use case without proven benefit to a broad spectrum of hardware or software. I think the complexity is significant and will be a net drag on all parts of the IR and IR-level transformations. But I don't really think it is useful to re-hash all these debates. Nothing relevant has changed in the years this has been discussed. > > > > That said, if I'm the only one who feels this way (and is willing to actually state this publicly), I'm not going to stop progress. > > > > You're not, and I'm in the same position here. I don't think there's a > really good answer for how this is going to affect a lot of the IR and > IR-level transformations from a maintainability perspective. It mostly > seems like this is a "we need this for the new ISA support" and while > I don't see a lot of compelling use case here and a lot of downside > that there... > > -eric > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Jacob Lifshay via llvm-dev
2019-Mar-19 01:16 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
On Mon, Mar 18, 2019 at 5:26 PM Bruce Hoult via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Three ISAs at present: > > - SVE in Aarch64 > - MVE in ARM Cortex-M (quite different from SVE) > - RVV in RISC-V > > It would not surprise me if other ISAs implement similar vector > extensions in future. >We're planning on implementing scalable vector support in the SimpleV ISA extension as well. Admittedly, we will most likely need additional IR modifications (allowing vectors of vectors), but I think having scalable vector support already built in will help greatly. Jacob Lifshay -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190318/c48f3423/attachment.html>
Erich Focht via llvm-dev
2019-Mar-19 06:54 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
On Mon, Mar 18, 2019 at 18:16:42 Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:> > Three ISAs at present: > > - SVE in Aarch64 > - MVE in ARM Cortex-M (quite different from SVE) > - RVV in RISC-V > > It would not surprise me if other ISAs implement similar vector > extensions in future. > > We're planning on implementing scalable vector support in the SimpleV > ISA extension as well. Admittedly, we will most likely need additional > IR modifications (allowing vectors of vectors), but I think having > scalable vector support already built in will help greatly. >As Simon Moll also wrote, please add the NEC SX-Aurora vector engine to the list of architectures aiming at and awaiting eagerly the SVE/AVL/VP changes in LLVM. We have long vectors (256x64bit) and a vector length register since many years, with the latest CPU being available on the market since a year, mainly aiming at HPC and AI. We're working on an LLVM backend and intend to open it and post an RFC on its inclusion soon. Progress with AVL/VP is very important for this backend and we rely on LLVM moving forward on these. Regards, Erich Focht
Graham Hunter via llvm-dev
2019-Mar-19 10:49 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
Hi Bruce,> On 19 Mar 2019, at 00:26, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Three ISAs at present: > > - SVE in Aarch64 > - MVE in ARM Cortex-M (quite different from SVE) > - RVV in RISC-VMVE isn't scalable in terms of registers (it's fixed at 128b iirc), so won't be using these types. It can use execution units that are narrower than 128b, and start execution on partially completed vectors in subsequent cycles (a bit like an RVV implementation might do when using VLMul > 1, or the established vector supercomputer architectures). Just a different set of design constraints. As Simon and Erich point out though, SX-Aurora would like to use scalable vectors too, so we still have three architectures intending to use the feature. -Graham> > It would not surprise me if other ISAs implement similar vector > extensions in future. > > On Mon, Mar 18, 2019 at 10:40 AM Eric Christopher via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>>> >>>> On 3/15/19 10:58 AM, David Greene wrote: >>>>> Renato Golin <rengolin at gmail.com> writes: >>>>> >>>>>> On Fri, 15 Mar 2019 at 15:30, Finkel, Hal J. via llvm-dev >>>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>>> I've talked with a number of people about this as well, and I think that >>>>>>> I understand the objections. I'm happy that ARM followed through with >>>>>>> the alternate set of patches. Regardless, however, unless those who had >>>>>>> wished to object still wish to object, and then actually do so, we now >>>>>>> clearly have a good collection of contributors actively desiring to do >>>>>>> code review, and we should move forward (i.e., start committing patches >>>>>>> once they're judged ready). >>>>>> Let's start by closing the three flying revisions, so that people that >>>>>> weren't involved in the discussion don't waste time looking at them. >>>>> See the reply I just posted to Hal. I am not sure we've made a decision >>>>> to abandon the current patches. We may in fact decide that, but I >>>>> haven't seen consensus for doing so yet. In fact I've seen the opposite >>>>> -- that people want to move forward with the scalable types. >>>> >>>> >>>> I agree with David. We should move forward with native support for >>>> scalable types. >>> >>> >>> Sorry I haven't been as available as usual for the past few weeks, but FWIW, I still am unconvinced that scalable vector types belong in the IR. >>> >>> I think this adds complexity to LLVM's IR to serve a niche use case without proven benefit to a broad spectrum of hardware or software. I think the complexity is significant and will be a net drag on all parts of the IR and IR-level transformations. But I don't really think it is useful to re-hash all these debates. Nothing relevant has changed in the years this has been discussed. >>> >>> That said, if I'm the only one who feels this way (and is willing to actually state this publicly), I'm not going to stop progress. >>> >> >> You're not, and I'm in the same position here. I don't think there's a >> really good answer for how this is going to affect a lot of the IR and >> IR-level transformations from a maintainability perspective. It mostly >> seems like this is a "we need this for the new ISA support" and while >> I don't see a lot of compelling use case here and a lot of downside >> that there... >> >> -eric >> _______________________________________________ >> LLVM Developers mailing list >> 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
Graham Hunter via llvm-dev
2019-Mar-19 11:11 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
Hi Eric and Chandler, I appreciate your concerns; I don't think the impact will be that great, but then it's rather easy for me to keep SVE in mind when working on other parts of the codebase given how long I've spent working on it. Are there any additional constraints on the scalable types you think would alleviate your concerns a little? At the moment we will prevent scalable vectors from being included in structs and arrays, but we could add more (at least to start with) to avoid potential hidden problems. I'm also trying to come up with an idea of how much impact we have in our downstream implementation; most places where there is divergence are in the AArch64 backend (as you'd expect), followed by the generic SelectionDAG code -- but lowering and legalization for current instructions should (hopefully) be a one-off. Do you have any specific parts of the codebase you're interested in a report into the extent of changes? -Graham> On 18 Mar 2019, at 17:39, Eric Christopher via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On 3/15/19 10:58 AM, David Greene wrote: >>>> Renato Golin <rengolin at gmail.com> writes: >>>> >>>>> On Fri, 15 Mar 2019 at 15:30, Finkel, Hal J. via llvm-dev >>>>> <llvm-dev at lists.llvm.org> wrote: >>>>>> I've talked with a number of people about this as well, and I think that >>>>>> I understand the objections. I'm happy that ARM followed through with >>>>>> the alternate set of patches. Regardless, however, unless those who had >>>>>> wished to object still wish to object, and then actually do so, we now >>>>>> clearly have a good collection of contributors actively desiring to do >>>>>> code review, and we should move forward (i.e., start committing patches >>>>>> once they're judged ready). >>>>> Let's start by closing the three flying revisions, so that people that >>>>> weren't involved in the discussion don't waste time looking at them. >>>> See the reply I just posted to Hal. I am not sure we've made a decision >>>> to abandon the current patches. We may in fact decide that, but I >>>> haven't seen consensus for doing so yet. In fact I've seen the opposite >>>> -- that people want to move forward with the scalable types. >>> >>> >>> I agree with David. We should move forward with native support for >>> scalable types. >> >> >> Sorry I haven't been as available as usual for the past few weeks, but FWIW, I still am unconvinced that scalable vector types belong in the IR. >> >> I think this adds complexity to LLVM's IR to serve a niche use case without proven benefit to a broad spectrum of hardware or software. I think the complexity is significant and will be a net drag on all parts of the IR and IR-level transformations. But I don't really think it is useful to re-hash all these debates. Nothing relevant has changed in the years this has been discussed. >> >> That said, if I'm the only one who feels this way (and is willing to actually state this publicly), I'm not going to stop progress. >> > > You're not, and I'm in the same position here. I don't think there's a > really good answer for how this is going to affect a lot of the IR and > IR-level transformations from a maintainability perspective. It mostly > seems like this is a "we need this for the new ISA support" and while > I don't see a lot of compelling use case here and a lot of downside > that there... > > -eric > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Chandler Carruth via llvm-dev
2019-Mar-19 19:31 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
On Tue, Mar 19, 2019 at 4:11 AM Graham Hunter <Graham.Hunter at arm.com> wrote:> Hi Eric and Chandler, > > I appreciate your concerns; I don't think the impact will be that great, > but then it's > rather easy for me to keep SVE in mind when working on other parts of the > codebase > given how long I've spent working on it. > > Are there any additional constraints on the scalable types you think would > alleviate > your concerns a little? At the moment we will prevent scalable vectors > from being > included in structs and arrays, but we could add more (at least to start > with) to > avoid potential hidden problems. >While the constraints you mention are good, and important, I don't think there are more that matter.> > I'm also trying to come up with an idea of how much impact we have in our > downstream > implementation; most places where there is divergence are in the AArch64 > backend (as you'd > expect), followed by the generic SelectionDAG code -- but lowering and > legalization for > current instructions should (hopefully) be a one-off. > > Do you have any specific parts of the codebase you're interested in a > report into the > extent of changes? >This is *not* about the changes required. It is about the long term (think 10-years) complexity forced onto the IR. We now have vectors that are unlike *all other vectors* in the IR. They're basically unlike all other types. I believe we will be finding bugs with this special case ~forever. Will it be an untenable burden? Definitely not. We can manage. But the question is: does the benefit outweigh the cost? IMO, no. I completely understand the benefit of this for the *ISA*, and I would encourage every ISA to adopt some vector instruction set with similar aspects. However, the more I talk with and work with my users doing SIMD programming (and my entire experience doing it personally) leads to me to believe this will be of extremely limited utility to model in the IR. There will be a small number of places where it can be used. All of those where performance matters will end up being tuned for *specific* widths anyways to get the last few % of performance. Those that aren't performance critical won't provide any substantial advantage over just being 128-bit vectorized or left scalar. At that point, we pay the complexity and maintenance cost of this completely special type in the IR for no material benefit. I've said this several times in various discussions. My opinion has not changed. No new information has been presented by others or by me. So I think debating this technical point is not really interesting at this point. That said, it is entirely possible that I am wrong about the utility. If the consensus in the community is that we should move forward, I'm not going to block forward progress. It sounds like Hal, the Cray folks, and many ARM folks are all positive. So far, only myself and Eric have said anything to the contrary. If there really isn't anyone else concerned with this, please just move forward. I think the cost of continuing to debate this is rapidly becoming unsustainable all on its own. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190319/303b933c/attachment.html>