On Mon, Dec 23, 2024 at 10:35 PM Robin Dapp <rdapp....@gmail.com> wrote: > > > +;; Integer Reduction (vred(sum|maxu|max|minu|min|and|or|xor).vs), but for > > auto vectorizer > > +(define_insn "@pred_av_<reduc_op><mode>" > > + [(set (match_operand:<V_LMUL1> 0 "register_operand" "=vr") > > + (unspec:<V_LMUL1> > > + [(unspec:<VM> > > + [(match_operand:<VM> 1 "vector_mask_operand" "vmWc1") > > + (match_operand 5 "vector_length_operand" " rK") > > + (match_operand 6 "const_int_operand" " i") > > + (match_operand 7 "const_int_operand" " i") > > + (reg:SI VL_REGNUM) > > + (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE) > > + (unspec:<V_LMUL1> [ > > + (match_operand:V_VLSI 3 "register_operand" " > > vr") > > + (match_operand:<V_LMUL1> 4 "register_operand" " > > vr") > > + ] ANY_REDUC_AV) > > + (match_operand:<V_LMUL1> 2 "vector_merge_operand" " vu")] > > UNSPEC_REDUC))] > > + "TARGET_VECTOR" > > + "v<reduc_op>.vs\t%0,%3,%4%p1" > > + [(set_attr "type" "vired") > > + (set_attr "mode" "<MODE>")]) > > Shouldn't operand 4 have a "0" constraint here and in the following two > changed > patterns? Or am I missing something?
Good catch, apparently I missed that and spec 2006 didn't catch that as well...:P Will update at V2, > I'm not yet fully convinced we should go with this approach over the one with > the additional vsetvl (that might get merged with a preceding vsetvl and I guess this might be hard to merge unless the preceding vsetvl come with a constant VL. And here is LLVM's one: https://github.com/llvm/llvm-project/blob/main/llvm/test/CodeGen/RISCV/rvv/vreductions-int-vp.ll I am not trying to say it's the best or only way to resolve...but that's the only way I found...so brainstorming start! :P > therefore free). > > -- > Regards > Robin >
