[llvm-dev] [RFC] Introduce a new stepvector operation

[Florian Hahn via llvm-dev]

> On Jan 22, 2021, at 13:26, David Sherwood <david.sherwood at arm.com> wrote:
> 
> Hi Florian,
>  
> RE: “Are you planning on updating the existing code that generates vector constants to use @llvm.stepvector for fixed width vectors?”
> Are you referring to InnerLoopVectorizer::getStepVector()? I guess this might be
> worthwhile for consistency and will ensure greater test coverage, provided it doesn’t
> cause regressions in code quality?
>  


If we can guarantee that stepvector and the corresponding constant generate the same code in all cases, that seems reasonable. But I guess that would mean we would have to update all places that look through shuffles to also support stepvector? That seems like this is going to potentially be a lot of work and it is easy to miss things (and we have to ensure all new optimizations also consider both cases). 

Will there be a lot of additional test coverage by using it? Are you anticipating most transforms to apply to both fixed width and scalable vectors?

What I am worried about is that we are claiming @llvm.stepvector behaves like the corresponding vector constant for fixed vectors, but then in practice run into situations where different code is generated, e.g. because we missed to update a transform to support both forms equally. I think it would be easier to avoid this problem altogether, by defining it away and allowing only scalable vector types for @llvm.stepvector, at least initially.

In terms of consistency/uniformity in LLVM code, we could have `Builder::CreateStepVector()` and `PatternMatch::m_StepVector` to unify creating and matching the different versions depending on the type.

Personally I also think using stepvector instead of fixed width vector constants like <0, 1, 2, 3> unnecessarily regresses the readability of the generated IR.


> With regards to the use of constants there is currently an ongoing discussion in
> another set of replies around the use of vector literals such as <0, 2, …> or
> <1, 3, …>, which you might be interested in? I agree that using an intrinsic should
> be quite straightforward, but there suggestions for changing how we deal with
> shufflevectors that would make use of such vector literals.
>  

I think extending vector literals would probably benefit from a wider context beyond stepvector and a wider audience, because it extends to scope of the proposal quite a bit. 

Cheers,
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210127/94b55532/attachment.html>