On Thu, May 21, 2026 at 10:37 PM Robin Dapp <[email protected]> wrote: > > > 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. >
before: i mean trunk. now: i mean trunk + my patch ditch the abd expander: ok > >> > + > >> > +(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). > Now I got it. Thanks. -- Zhongyao
