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

[Chandler Carruth via llvm-dev]

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>