[llvm] [RISCV] Fold vp.reverse of vp.load through binary ops (PR #205529)

[Min-Yih Hsu via llvm-commits]

mshockwave wrote:

> > I agree this isn't generally true. An implementation could have strided load implemented 1 element at a time and vrgather implemented quadratic in lmul, for example. With lmul=1 the vrgather could be better.
> 
> Yes, this is an assumption we already make for the existing single load fold. I.e it's possible for a single vlse.v to be slower than a vrgather.vv.
> 
> Do we need to address this in this PR? It might be better to revisit this later with a tuning feature for the combine entirely.

I guess the tricky thing here is that vrgather.vv might only be faster in some LMULs but slower in others. So I'm not sure if a binary tuning feature will cut it, and perhaps cost model is still the most comprehensive solution. 

I wonder if we can guard this combine with some simple cost estimations before the vectorizer change lands. For instance `getVRGatherVVCost` is already in TLI, not sure if we can approximate the cost of strided load here as well though. 

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