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

[Mel Chen via llvm-commits]

Mel-Chen wrote:

Let me summarize the three approaches so far:

First approach: Unconditionally convert all reverse in the vectorized loop to vp.reverse. This is simple, but may temporarily produce incorrect semantics during the EVL lowering phase.

Second approach: In optimizeMaskToEVL, convert the reverse operation of reverse stored value to vp.reverse, but for reverse load results, convert them outside of optimizeMaskToEVL by visiting the def-use chain of the result. This may temporarily produce incorrect semantics for reverse load, but not for reverse store. Even if the reverse is later moved or simplified, the reverse load can still be converted to an EVL reverse load, so performance is not affected.

Third approach: Convert all reverse inside optimizeMaskToEVL. There is no temporary incorrect semantics, but if the reverse is later moved or simplified, some reverse load may not be convertible to EVL reverse load. This could temporarily impact tail folding performance by EVL. This can later be improved by replacing vp.reverse with llvm.splice + llvm.reverse.

Essentially, the difference between the second and third approaches lies only in the treatment of reverse load.

> I don't see any way forward other than doing it optimizeMaskToEVL, i.e. in [3250467](https://github.com/llvm/llvm-project/commit/32504676f616a98d3282ef2601550e6ed3e25714). Having the VPlan be in an incorrect state temporarily makes things much harder to reason about and is likely to lead to more subtle miscompiles down the line.
> 
> After this PR I am confident we can rewrite the reverse -> vp.reverse pattern in terms of slides which should address the issue when two reverses are folded away.

Yes, the current patch already uses the third approach. Since all three approaches have their pros and cons, what I want to know now is which approach we should proceed with.

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