> Since it was already an expand before my patch, I didn't think about > changing it. > I've checked and PR119224 is indeed resolved. > However, after changing from define_expand to define_insn_and_split, > pr117722.c regressed. > It now gets recognized as abd instead of sub + abs. > > now it generates: > vmaxu.vv > vminu.vv > vsub.vv > vzext.vf4 > vadd.vv > > before: > vwsubu.vv > vwsubu.vv > vmax.vv > vwadd.wv > > Should I also update the test expectations for this case? I'm not sure.
What's "before" and "now"? There have been some concerns about the widening variants (potentially less throughput or higher latency) but I think this is not relevant anymore. So, I guess we can just ditch the abd expander if there's no vabd instruction. >> > + >> > +(define_insn_and_split "*abd<su><mode>3" >> > + [(set (match_operand:V_VLSI 0 "register_operand" "=vr") >> > + (unspec:V_VLSI >> > + [(match_operand:V_VLSI 1 "register_operand" "vr") >> > + (match_operand:V_VLSI 2 "register_operand" "vr")] >> > + UNSPEC_VABD))] >> > + "TARGET_VECTOR && (TARGET_ZVABD || can_create_pseudo_p ())" >> >> We also need can_create_pseudo_p for ZVABD, so just drop TARGET_ZVABD here. >> > > dont understand why need can_create_pseudo_p for ZVABD，but ok to change it。 Our define_insn_and_splits can potentially be triggered after reload and if the vector length happens to be > 31 we need to be able to emit a vsetvl with a register (vsetivli can only encode up to vl = 31). >> > +} >> > +[(set_attr "type" "viwalu")]) >> > + >> > +(define_insn_and_split "*vwabdacc_right<su><mode>4" >> >> That's needed because we don't canonicalize the plus in the presence of an >> unspec? -- Regards Robin
