[llvm-dev] Scalable Vector Types in IR - Next Steps?

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 15 09:49:45 PDT 2019


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>


More information about the llvm-dev mailing list