[llvm] [LV][POC] Use umin to avoid second-to-last iteration problems with EVL (PR #143434)

[Mel Chen via llvm-commits]

https://github.com/Mel-Chen commented:

This is aa interesting approach. I have a few questions on my end:

> This breaks a bunch of assumptions in the vectorizer, and has required a bunch of work to address, with some of that work still in progress.

Besides the work on the widen Induction recipe, is there anything else currently related to the penultimate EVL issue?

> Interestingly, that improvement comes primarily by unblocking vectorization cases that the current EVL code can't handle.

Did you exclude the cases that current EVL code can't vectorize when comparing the numbers? I think that would give a clearer picture of the actual difference between the two approaches.

> RISCV supports VL predication via the VL configuration register. The specification has an special case for the case when the requested AVL is between VLMAX and VLMAX*2 when a vsetvl instruction is executed.

The last question might be more related to the ISA spec. I've always been curious about this particular design in the RISC-V spec—what exactly is its purpose? Is it meant to benefit hardware performance, or is there another reason behind it? If this design does provide advantages for certain hardware, should we consider preserving the original approach when implementing the new EVL method, and allow the choice between the two via TTI or an option?

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