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

[via llvm-dev]

Renato Golin <renato.golin at linaro.org> writes:

>> This is another case where an Instruction might be better, for the same
>> reasons as with vscale.
>
> This is a side-effect of the original RFC a few years ago. The general
> feeling was that we can start with intrinsics and, if they work, we
> change the IR.
>
> We can have a work-in-progress implementation before fully committing
> SCEV and other more core ideas in, and then slowly, and with more
> certainty, move where it makes more sense.

Ok, that makes sense.  I do think the goal should be making these proper
Instructions.

>> Also, "iota" is the name Cray has traditionally used for this operation
>> as it is the mathematical name for the concept.  It's also used by C++
>> and go and so should be familiar to many people.
>
> That sounds better, but stepvector is more than C++'s iota and it's
> just a plain scalar evolution sequence like {start, op, step}. In
> C++'s iota (AFAICS), the step is always 1.

I thought stepvector was also always step one, as Graham states a
multiply by a constant splat must be used for other step values.

> Anyway, I don't mind any name, really. Whatever is more mnemonic.

Me neither.  I was simply noting some of the history surrounding the
operation and naming in other familiar places.

>>  ;; Create sequence for scalable vector
>>  %stepvector = call <scalable 4 x i32> @llvm.experimental.vector.stepvector.nxv4i32()
>>  %mulbystride = mul <scalable 4 x i32> %stepvector, %str_off
>>  %addoffset = add <scalable 4 x i32> %mulbystride, %str_off
>
> Once stepvetor (or iota) becomes a proper IR instruction, I'd like to
> see this restricted to inlined syntax. The sequence { step*vec +
> offset } only makes sense in the scalable context and the intermediate
> results should not be used elsewhere.

I'm not so sure.  iota is a generally useful operation and scaling it to
various step values is also useful.  It's used often for strided memory
access, which would be done via gather/scatter in LLVM but generating a
vector GEP via stepvector would be convenient and convey more semantic
information than, say, loading a constant vector of indices to feed the
GEP.

                               -David