[llvm] [LV] Run simplifyRecipes after addExplicitVectorLength (PR #200794)

[Mel Chen via llvm-commits]

Mel-Chen wrote:

There are two main purposes for inserting `simplifyRecipes` at this specific location:
1. Maintaining NFC before `vector.reverse` elimination: Before eliminating `vector.reverse`, it allows the new patch for EVL reverse access transformation to remain as NFC as possible. To achieve this, we need certain simplification rules that still generate `vp.reverse` so that the cost is unaffected:

```
vector.reverse(splice.left(poison, v, evl))
-->
vp.reverse(v, true, evl)

splice.right(vector.reverse(v), poison, evl)
-->
vp.reverse(v, true, evl)
```
Note: This is intended to be temporary, as the long-term plan is to eliminate `vp.reverse` intrinsic entirely.

2. Cleaning up redundant splices after `vector.reverse` elimination: Once `vector.reverse` is optimized away, `optimizeMasksForEVL` might leave some redundant splices. Therefore, we need a simplification rule to clean up redundant splice pairs:

```
splice.right(splice.left(poison, val, evl), poison, evl) -> val
```
The current side-effects generated by this patch were not entirely what I intended, which created some unwanted noise that complicates the review in #199510. Even though it applies rules that are typically only relevant post-unrolling, most of these simplifications don't seem to have a material impact on the final cost.

If we want to avoid inserting `simplifyRecipes` directly into the EVL path, we could consider extracting these simplification rules, including the `vector.reverse` ones, into a new transformation (perhaps named `simplifyPermutations`). Then, we can invoke this new transformation on the EVL path instead of `simplifyRecipes`.

@fhahn @lukel97 @david-arm What do you all think?

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