[llvm] [VPlan] Extract reverse operation for reverse accesses (PR #146525)

[Mel Chen via llvm-commits]

Mel-Chen wrote:

> > Rebased and ping. There are currently two points that may require further discussion:
> > ```
> > 1. When converting to vp.reverse, should we eagerly convert all reverse operations, or should we only convert those whose results are used by a vp.load or consumed by a vp.store?
> >    The current implementation uses the latter (more conservative) strategy, but the former would be simpler.
> > ```
> 
> From [#146525 (comment)](https://github.com/llvm/llvm-project/pull/146525#discussion_r2348512773), it sounds like converting them all would be simpler and also valid/correct, if so good to go with the simpler option to start with?
> 

Sure, revert to the original approach: directly convert all reverses in the vector loop region to vp.reverse, and leave a TODO to document a more complex conversion method.

> > ```
> > 2. We currently do not convert reverse operations defined outside the loop region into vp.reverse.
> >    Besides the fact that EVL is not available in that region, such reversed stored values should be uniform.
> >    If we think this is unsafe, we could instead move that reverse operation back into the vector loop and still convert it to vp.reverse. Later, this can be cleaned up by a rule like
> >    `Reverse(Splat(V)) --> Splat(V)`
> >    in SimplifyRecipes to eliminate the unnecessary reverse.
> > ```
> 
> EVL would be available in the middle block, but not blocks before the loop region. Do we have such cases? Can we verify? Any reverse hoisted to the loop should have a single-scalar operand, if so we the reverse can be removed independently I think

`llvm/test/Transforms/LoopVectorize/RISCV/tail-folding-uniform-store.ll` show the issue. The reverse stored value is hoisted to preheader since the stored value is all zero. I think we can optimize it in SimplifyRecipes after this patch.



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