[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

[Renato Golin via llvm-dev]

On Tue, 31 Jul 2018 at 20:10, David A. Greene <dag at cray.com> wrote:
> Me too.  Thanks Robin for clarifying this for all of us!  I'll try to
> follow this terminology:

+1


> TL;DR - Changing VL in a function doesn't affect anything about this
>         proposal, but changing vscale might.  Changing VL shouldn't
>         impact things like ISel at all but changing vscale might.
>         Changing vscale is (much) more difficult than changing VL.

Absolutely agreed. :)


> Right.  Changing VL is no problem.  I think even reducing vscale is ok
> from an IR perspective, if a little strange.

Yup.


> You mean going from a shorter active vector length to a longer active
> vector length?  Or smaller vscale to larger vscale?  The latter would be
> bad.

The latter. Bad indeed.


> If a function changes vscale, I don't know.  The RISC-V people seem to
> have thought the most about this.  I have no point of reference here.

I think the consensus is that this would be bad. So we should maybe
encode it as an error.


> Yes, the "is this supported" question is common.  Isn't the whole point
> of VPlan to get the "which one is better" question answered for
> vectorization?

Yes, but the cost is high. We can have that in the vectoriser, as it's
a heavy pass and we're conscious, but we shouldn't make all other
passes "that smart".


> Changing vscale *would* impact the IR and codegen (stack allocation,
> etc.).  Changing VL would not, other than adding some Instructions to
> capture the semantics.  I suspect neither would change ISel (I know VL
> would not) but as you say I don't think we need concern ourselves with
> changing vscale right now, unless others have a dire need to support it.

Perfect! :)


> Perhaps changing VL could be modeled the same way but I have a feeling
> it will be awkward.  Changing vscale is something totally different and
> likely should be represented differently if allowed at all.

Right, I was talking about vscale.

It would be awkward, but if this is the only thing the hardware
supports (ie. no predication), than it's up to the back-end to lower
how it sees fit.

In IR, we still see as a predication.


> Again trying to use the VL/vscale terminology:
>
> Changing vscale - no IR support currently and less likely in the future
> Changing VL     - no IR support currently but more likely in the future

SGTM.


> The second seems like a straightforward extension to me.  There will be
> some questions about how to represent VL semantics in IR but those don't
> impact the proposal under discussion at all.

Should be equivalent to predication, I imagine.


> The first seems much harder, at least within a function.

And it would require exposing the instruction to change it in IR.


>  It may or may not impact the proposal under discussion.

As per Robin's email, it doesn't. Functions are vscale boundaries in
their current proposal.

-- 
cheers,
--renato