[llvm-dev] [RFC] Supporting ARM's SVE in LLVM

[Paul Walker via llvm-dev]

Hi Renato,

I’m just revisiting the seriesvector question you had a couple of days back.

>>%const_vec = <n x 4 x i32> @llvm.sve.constant_vector(i32 %start, i32 %step)
>>
>>This intrinsic matches the seriesvector instruction we original proposed.  However, on reflection we didn't like how it allowed multiple representations for the same >>constant.
>
>Can you expand how this allows multiple representations for the same constant?
>
>This is a series, with a start and a step, and will only be identical
>to another which has the same start and step.
>
>Just like C constants can "appear" different...
>
>const int foo = 4;
>const int bar = foo;
>const int baz = 2 + 2;

With the original "seriesvector" proposal the sequence 0, 2, 4, 6, 8... can be built is multiple ways:

(1)	seriesvector(i32 0, i32 2)
(2)	mul(seriesvector(i32 0, i32,1), splat(2))

Both patterns are likely to occur and so must be matched within InstCombine and friends.  The solution could be to first simplify seriesvector related IR to a canonical form so only a single pattern requires matching against.  The "stepvector" proposal asks why we would bother introducing the problem in the first place and instead force a canonical representation from the outset.

Obviously there will exist new idioms to canonicalise ((2*stepvector) + stepvector <==> 3*stepvector) but at least the most common cases are handled automatically.

We made this change when creating the upstream patch for "seriesvector" and observed its effect on the code base.  When switching to "stepvector" the resulting patch was about 1/5 the size.  That said if a constant intrinsic is the way to go then I imagine said patch will be even smaller.

> One way to make your "seriesvector" concept show up *before* any spec
> is out is to apply it to non-scalable vectors.

That is my intention with the stepvector patch (https://reviews.llvm.org/D27105).  You can see that the interface is common but for non-scalable vectors the result is its equivalent ConstantVector.  Once an agreed form is available LoopVectorize::getStepVector can be converted to become compatible with scalable vectors very easily, albeit being only a small step on a long road.

	Paul!!!