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

On 5 June 2018 at 16:23,  <dag at cray.com> wrote:
> The name "getSizeExpressionInBits" makes me think that a Value
> expression will be returned (something like a ConstantExpr that uses
> vscale).  I would be surprised to get a pair of integers back.
Same here.

> If we went the ConstantExpr route and added ConstantExpr support to
> ScalarEvolution, then SCEVs could be compared to do this size
> comparison.
This sounds like a cleaner solution.

> I think this may be a case where added a full-fledged Instruction might
> be worthwhile.  Because vscale is intimately tied to addressing, it
> seems like things such as ScalarEvolution support will be important.  I
> don't know what's involved in making intrinsics work with
> ScalarEvolution but it seems strangely odd that a key component of IR
> computation would live outside the IR proper, in the sense that all
> other fundamental addressing operations are Instructions.
...
> 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.

> 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.

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

>  ;; 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.


-- 
cheers,
--renato

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

On 5 June 2018 at 18:38,  <dag at cray.com> wrote:
> I thought stepvector was also always step one, as Graham states a
> multiply by a constant splat must be used for other step values.
You're right! Sorry, it's been a while. Step-vector is a simple iota,
the multiplier and offset come form the operations.

> 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.
My point is that those patterns will be generated by C-level
intrinsics or IR optimisation passes (like vectorisers), so they have
a specific meaning in that context.

What I fear is if some other pass like CSE finds the patterns out and
common them up at the top of the function/BB and then the back-end
loses sight of what that was and can't generate the step increment
instruction in the end.

-- 
cheers,
--renato