on 2023/4/14 14:39, juzhe.zh...@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
