Renato Golin via llvm-dev
2019-Mar-15 17:20 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
On Fri, 15 Mar 2019 at 16:50, James Y Knight <jyknight at google.com> wrote:>> Ie. the current series is already dead, no matter what we do > > But this last statement seems odd. So far, there looks to be a fairly good consensus from a number of experienced llvm developers that the approach seems like a good idea, both on this thread, and from skimming the earlier threads you linked from your original message. > > Doesn't that mean that the reasonable next step is to continue moving forward with the existing patch set?It depends. The previous public consensus was, indeed, that the native proposal makes a lot of sense. I think this is ultimately where we want to be, but I'm not clear on what the path really is.>From what Graham said, and from his current work, I guess the "new"(not public) consensus seems to be to go with intrinsics first, then move to native support, which is a valid path. If the public agreement becomes that this is the path we want to take, then that specific patch-set is dead, because even if we do native, it will be a different set. If the end result is that we'll stop at intrinsics (I really hope not), the patch-set is also dead. However, if people want to continue pushing for native support now, the patch-set is not dead. But then we need to re-do the meeting that happened in the US dev meeting with everyone in it, which won't happen. So, while I would also prefer to have native support first, and work our the wrinkles between releases (as I proposed in this thread), I'm ok with going the intrinsics way first, as long as the aim is to not stop there. Makes sense? cheers, --renato PS: Until someone writes up what happened, who was involved, what were the issues and why the current consensus is changed, we can only guess...
Graham Hunter via llvm-dev
2019-Mar-15 19:50 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
Hi,> From what Graham said, and from his current work, I guess the "new" > (not public) consensus seems to be to go with intrinsics first, then > move to native support, which is a valid path.There wasn't a consensus, just a proposal for a different option to present to the community for feedback and discussion to get things moving (whether for the full scalable IR proposal, the opaque types one, or something in between). Sorry if I didn't make that clear enough. Arm felt it was worth investing some time in investigating an alternative if there was the possibility of progressing upstreaming, then presenting the findings for discussion.> If the public agreement becomes that this is the path we want to take, > then that specific patch-set is dead, because even if we do native, it > will be a different set. > > If the end result is that we'll stop at intrinsics (I really hope > not), the patch-set is also dead. > > However, if people want to continue pushing for native support now, > the patch-set is not dead. But then we need to re-do the meeting that > happened in the US dev meeting with everyone in it, which won't > happen.While there was a roundtable at the devmeeting last year, there weren't that many people in attendance to talk purely about SVE or scalable types -- most of the discussion revolved around predication support, from what I remember. The main feedback I had which led to changes in the RFC were in side chats when people had a few minutes of spare time (since they had other sessions to attend which clashed with the roundtable slots). -Graham
Renato Golin via llvm-dev
2019-Mar-15 20:07 UTC
[llvm-dev] Scalable Vector Types in IR - Next Steps?
Hi Graham, By the extent of your "further work" , I assumed you had quite a strong push back and that this was more of an official session. That's why I wanted clarity over which reviews we should be looking at. Honestly, so far, no one in this thread has pointed to any concrete request for non native support, so unless someone does so, the official consensus is still native. So, with apologies to all bystanders, I repeat my original proposal: it's now time to try and push native support (time to next release) on trunk. If anyone has concerns, either on the current proposal (reviews on my first email) or on the general idea of native scalable types, please speak up. As David said, it's a bit silly that gcc has support for it for over a year and we're still arguing about very basic stuff. Cheers, Renato On Fri, 15 Mar 2019, 19:50 Graham Hunter, <Graham.Hunter at arm.com> wrote:> Hi, > > > From what Graham said, and from his current work, I guess the "new" > > (not public) consensus seems to be to go with intrinsics first, then > > move to native support, which is a valid path. > > There wasn't a consensus, just a proposal for a different option to > present to the community for feedback and discussion to get things > moving (whether for the full scalable IR proposal, the opaque types one, > or something in between). Sorry if I didn't make that clear enough. > > Arm felt it was worth investing some time in investigating an alternative > if there was the possibility of progressing upstreaming, then presenting > the findings for discussion. > > > If the public agreement becomes that this is the path we want to take, > > then that specific patch-set is dead, because even if we do native, it > > will be a different set. > > > > If the end result is that we'll stop at intrinsics (I really hope > > not), the patch-set is also dead. > > > > However, if people want to continue pushing for native support now, > > the patch-set is not dead. But then we need to re-do the meeting that > > happened in the US dev meeting with everyone in it, which won't > > happen. > > While there was a roundtable at the devmeeting last year, there weren't > that many people in attendance to talk purely about SVE or scalable > types -- most of the discussion revolved around predication support, > from what I remember. > > The main feedback I had which led to changes in the RFC were in side chats > when people had a few minutes of spare time (since they had other sessions > to attend which clashed with the roundtable slots). > > -Graham > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190315/560b5907/attachment.html>