>> 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.
>> 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 all your comments. juzhe.zh...@rivai.ai From: Kewen.Lin Date: 2023-04-14 14:31 To: juzhe.zh...@rivai.ai CC: gcc-patches; jeffreyalaw; rdapp; richard.sandiford; rguenther Subject: Re: [PATCH] VECT: Add WHILE_LEN pattern for decrement IV support for auto-vectorization Hi Juzhe, on 2023/4/14 11:39, juzhe.zh...@rivai.ai wrote: > And also I already decided to make remove WHILE_LEN pattern since it seems to > be unnecessary. > And as Richard said, it's just a simple airthmetic and it's not worthwhile to > do that. > > So, I plan to replace WHILE_LEN into MIN_EXPR and make everything RVV > > specific done in RISC-V port. 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? [1] https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615634.html > I think it's more reasonable for IBM use and more target use in the future. > If RV needs WHILE_LEN, IMHO they can co-exist, like: for ports defining len_{load,store} but no while_len, use MIN; for ports defining while_len, then use WHILE_LEN. > So, this patch will need to changed as "introduce a new flow to do > vectorization loop control" which is a new loop control flow > with saturating subtracting n down to zero, and add a target hook for it so > that we can switch to this flow ? 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. BR, Kewen
