llvm dev - Mar 2019 - Scalable Vector Types in IR - Next Steps?

On Fri, 15 Mar 2019 at 15:58, David Greene <dag at cray.com>
wrote:
> 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 did see that reply.

While, like Hal, I do understand some concerns on introducing a
radical new concept to IR (the reason why I started this thread), I'm
unaware (mainly by not being on that meeting) of the individual issues
and how controversial they were with those involved.

Furthermore, the current state is uncertain and people need to be
convinced more of what will work by means of hacking up more
intrinsics and more kludge into the current IR.

This means that, even if we are to implement it natively in IR, it
won't come *before* we implement it with intrinsics, which will
hopefully convince people that this makes sense, and by which time,
the code will look completely different and we'll need a completely
new patch.

Ie. the current series is already dead, no matter what we do.

cheers,
--renato

On Fri, Mar 15, 2019 at 12:11 PM Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Fri, 15 Mar 2019 at 15:58, David Greene <dag at cray.com> wrote:
> > 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 did see that reply.
>
> While, like Hal, I do understand some concerns on introducing a
> radical new concept to IR (the reason why I started this thread), I'm
> unaware (mainly by not being on that meeting) of the individual issues
> and how controversial they were with those involved.
>
> Furthermore, the current state is uncertain and people need to be
> convinced more of what will work by means of hacking up more
> intrinsics and more kludge into the current IR.
>
> This means that, even if we are to implement it natively in IR, it
> won't come *before* we implement it with intrinsics, which will
> hopefully convince people that this makes sense, and by which time,
> the code will look completely different and we'll need a completely
> new patch.
>
> Ie. the current series is already dead, no matter what we do

I have no opinion on the technical aspects here, not having researched this
topic at all.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190315/2339b139/attachment.html>

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...