[llvm] [LV] Support strided load with a stride of -1 (PR #128718)

[Mel Chen via llvm-commits]

================
@@ -1115,6 +1115,7 @@ class LoopVectorizationCostModel {
     CM_Widen_Reverse, // For consecutive accesses with stride -1.
     CM_Interleave,
     CM_GatherScatter,
+    CM_Strided,
----------------
Mel-Chen wrote:

I believe the main challenge is interleaved access and strided access.
The interleaved accesses: https://godbolt.org/z/eTcjvxYGK
In the same code, gather/scatter vector pointers with a stride of 2 can be transformed into strided loads/stores in the future: https://godbolt.org/z/hfhx953a8

If we realize during VPlan transforms that strided access is more profitable than interleaved access, converting interleaved accesses into strided ones would require splitting them back into multiple strided accesses.
Moreover, if an interleaved access originally requires a scalar epilogue due to a tail gap, 
```
void foo (int *A, int *B, int N) {
    int i;
    for (i = 0; i < N; ++i) {
        A[i*3] = B[i*3] + 1;
        A[i*3 + 1] = B[i*3 + 1] + 1;
        // No access [i*3+2], this is gap in the end of interleave group, requires scalar epilogue.
    }
}
```
such a requirement will disappear once it's converted into strided accesses. In that case, we would also need to modify the VPlan loop skeleton during the VPlan transform.
Given all that, the most we can do for now is something similar to what `VPTransform::createInterleaveGroup` currently does—decide whether to generate strided accesses before the VPlan is built, using an `enum InstWidening` to collect the necessary information, and then create a new `VPTransform::createStridedAccesses` to generate VPWidenStridedLoad/Store recipes.

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