[RISCV][EVL] Improve sdiv/udiv code generation for tail folding by EVL.

[Mel-Chen]

After #127180, the vectorizer emits vp.merge + general sdiv/udiv instead of vp.sdiv/udiv for tail folding by EVL.
However, using vp.udiv/sdiv may yield better performance. The improvement could come from fewer vsetvli instructions and lower vector register pressure.

The current IR and assembly for sdiv: https://godbolt.org/z/YvPhGa8df
The vp intrinsic IR and assembly for sdiv: https://godbolt.org/z/1achsE3Wo

Not yet sure at which stage this optimization should be applied. We need more discussion.
Label it as RISCV backend issue for now.

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Mel Chen (Mel-Chen)

After https://github.com//pull/127180, the vectorizer emits vp.merge + general sdiv/udiv instead of vp.sdiv/udiv for tail folding by EVL. However, using vp.udiv/sdiv may yield better performance. The improvement could come from fewer vsetvli instructions and lower vector register pressure.

The current IR and assembly for sdiv: https://godbolt.org/z/YvPhGa8df
The vp intrinsic IR and assembly for sdiv: https://godbolt.org/z/1achsE3Wo

Not yet sure at which stage this optimization should be applied. We need more discussion.
Label it as RISCV backend issue for now.

[Mel-Chen]

CC @topperc @preames @lukel97 @wangpc-pp @LiqinWeng @kito-cheng

[lukel97]

I think emitting a VP intrinsic here (also possibly for masked folding?) makes sense.

After #127180, the vectorizer emits vp.merge + general sdiv/udiv instead of vp.sdiv/udiv for tail folding by EVL.

Just to check, my understanding was that before #127180 we still emitted a vp.merge (previously a select on LLVM 19: https://godbolt.org/z/bqGzxbWr5)

We could either try and fold it away to a VPWidenIntrinsicRecipe in transformRecipestoEVLRecipes, or emit it directly in VPRecipeBuilder::tryToWiden. I think the former might be cleaner if it means we can keep the EVL stuff in one place.

This potentially motivates the need for #125991

[Mel-Chen]

I think emitting a VP intrinsic here (also possibly for masked folding?) makes sense.

If possible, I still prefer handling it in the backend to share more optimization resources. However, if it is too hard to handle it in the backend, we can address this issue in the vectorizer instead.

Just to check, my understanding was that before #127180 we still emitted a vp.merge (previously a select on LLVM 19: https://godbolt.org/z/bqGzxbWr5)

Oh... I originally thought that masked_divisor = vp.merge(true, divisor, X, evl) + vp.sdiv/udiv(dividend, masked_divisor, mask, evl) could be combined into vp.sdiv/udiv(dividend, divisor, mask, evl). In that case, this indeed has little to do with #127180.