[llvm-branch-commits] [llvm] [LV][REVEC] Initial support for re-vectorisation (PR #208213)

[Florian Hahn via llvm-branch-commits]

=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>,
=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>,
=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>,
=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>,
=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>,
=?utf-8?q?Gaëtan?= Bossu <gaetan.bossu at arm.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/208213 at github.com>


https://github.com/fhahn commented:

> Thanks for looking into this PR :)
> 
> > I think it would be good to clarify somewhere what the new expectations are for places that previously dealt with scalar element types only and what they should hold in the REVEC path and why
> 
> Ultimately, the set of features supported for REVEC will be very close to the set of features for scalar->vector vectorisation. This means the "scalar type" that recipes/transforms refer to might actually be a vector type. Most of them transparently support "vector lane types", but some need adjustments like `Select`. Induction variables are an exception where we still only expect scalar types. I can try to summarise that somewhere, maybe at the top of `LoopVectorize.cpp`?
> 
> Note: I think "scalar type" should now the called "initial type" instead.


This would be good to explain in the PR description, which is quite light on details. It is not immediately clear why we need to store the vector type instead of the scalar type? Conceptually, it would be clearer if we would treat revec 'just' as a normalization of an input loop with vectors to one with scalar types, that can be widened to whatever VF is chosen (smaller or larger than the input). If that is not possible, it would be good to clarify.

It would also be helpful to provide more details in the PR description of how the approach works and why.

https://github.com/llvm/llvm-project/pull/208213