[llvm] [LV] Introduce the EVLIVSimplify Pass for EVL-vectorized loops (PR #91796)

[Min-Yih Hsu via llvm-commits]

mshockwave wrote:

I'd just updated this PR to use a new exit condition. Previously, the exit condition of the new EVL-based loop was implemented by comparing IV against a trip count retrieved from IR pattern matching. This turned out to be risky since the said condition was not derived from the original canonical loop, so there is a chance that the number of iterations of the new EVL-based loop might not match that of the original loop.

The new exit condition is `EVLIV > VF * BTC`, where `EVLIV` is the new induction variable, `VF` is the vectorization factor and `BTC` is backedge taken count (i.e. trip count minus one in most cases). I think I have a proof written somewhere showing that this new condition is sound. I'll share the proof here once I found it. It is worth noting that this new exit condition is based upon the new semantics of `llvm.experimental.get.vector.length` landed in https://github.com/llvm/llvm-project/commit/e8063702cfbbf39f0b92283d0588dee264b5eb2b.

I've verified the correctness of the new exit condition with SPEC2006INT and SPEC2017INTRATE. In these two suites, the dynamic instruction counts keep mostly the same, with minor (<1%) improvements in some benchmarks.

One thing which I haven't had a good solution yet is the fact that SCEVExpander (or just ScalarEvolution in general) couldn't simplify the SCEV expression for `VF * BTC` in some cases. For instance, the `@simple` function in `test/CodeGen/RISCV/evl-iv-simplify.ll` uses a bunch of division and multiplication to build the said expression. Though in cases where `vscale_range` are singular ScalarEvolution successfully simplifies the expression. Plus, my experiments also showed that the dynamic instruction counts barely increase. @preames what do you think on this particular issue?

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