Re: [PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for auto-vectorization

["Kewen.Lin" <linkw@linux.ibm.com>]

on 2023/4/14 14:39, juzhe.zhong@rivai.ai wrote:
>>> Yeah, MIN_EXPR is enough for IBM ports, but with seeing the special semantic of vsetvli on
>>> "vl = ceil(AVL / 2) for VLMAX < AVL < 2*VLMAX", I'm not sure if it's a good idea for RV, it seems
>>> to put the burden to RV backend.  For one case that the iteration count is known, on the environment
>>> with the above capability, using the vector setting as [1], assuming the given iterations is 10,
>>> fully unrolled, when using MIN_EXPR, the lengths for two iterations would be folded into 8/2, while
>>> using WHILE_LEN artificial folding can make the lengths be 5/5.  I assumed that on the environment
>>> with the above capability 5/5 is optimal than 8/2? that means if we use MIN then RV backend has to
>>> try to make 8/2 to 5/5.  Or it's trivial since RV backend already supports and plans to support this
>>> kind of vsetvli load re-balancing?
> This is a trivial power optimization feature of RVV. I don't think making it in middle-end is a good idea
> since the middle-end is supposed to be totally target-independent. And I figured out re-balancing
> vsetvli is not difficult to do that in RISC-V port. 
> 

OK, thanks for clarifying, sounds good.

> 
>>> Yes, if you don't need WHILE_LEN, this proposal is more like to enhance the current partial
>>> vectorization with length (mainly on length preparation and loop control).  But why would we need
>>> a new target hook?  You want to keep the existing length handlings in vect_set_loop_controls_directly
>>> unchanged? it seems not necessary.  IIUC, not requiring WHILE_LEN also means that this patch
>>> doesn't necessarily block the other RV backend patches on vector with length exploitation since
>>> the existing vector with length support already works well on functionality.
> Ok, I get your point. I am gonna refine the patch to make it work for both RVV and IBM.

Thanks!

BR,
Kewen