> +;; 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? 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 therefore free). -- Regards Robin
