Richard Henderson <r...@twiddle.net> writes: > @@ -2687,34 +2738,60 @@ > aarch64_sve_prepare_conditional_op (operands, 5, <commutative>); > }) > > -;; Predicated floating-point operations. > -(define_insn "*cond_<optab><mode>" > - [(set (match_operand:SVE_F 0 "register_operand" "=w") > +;; Predicated floating-point operations with select matching output. > +(define_insn "*cond_<optab><mode>_0" > + [(set (match_operand:SVE_F 0 "register_operand" "+w, w, ?&w") > (unspec:SVE_F > - [(match_operand:<VPRED> 1 "register_operand" "Upl") > + [(match_operand:<VPRED> 1 "register_operand" "Upl, Upl, Upl") > (unspec:SVE_F > - [(match_operand:SVE_F 2 "register_operand" "0") > - (match_operand:SVE_F 3 "register_operand" "w")] > + [(match_dup 1) > + (match_operand:SVE_F 2 "register_operand" "0, w, w") > + (match_operand:SVE_F 3 "register_operand" "w, 0, w")] > + SVE_COND_FP_BINARY) > + (match_dup 0)] > + UNSPEC_SEL))] > + "TARGET_SVE" > + "@ > + <sve_fp_op>\t%0.<Vetype>, %1/m, %0.<Vetype>, %3.<Vetype> > + <sve_fp_op_rev>\t%0.<Vetype>, %1/m, %0.<Vetype>, %2.<Vetype> > + movprfx\t%0, %1/m, %2\;<sve_fp_op>\t%0.<Vetype>, %1/m, %0.<Vetype>, > %3.<Vetype>" > + [(set_attr "movprfx" "*,*,yes")] > +)
Reintroduces a (match_dup 1) into the SVE_COND_FP_BINARY. OK otherwise, thanks. The original reason for using SVE_COND_FP_BINARY rather than rtx codes was to emphasise that nothing happens for inactive lanes: this is really a predicated operation that returns "don't care" values for inactive lanes fused with a select that "happens" to use (but in fact always uses) the same predicate. So from that point of view it seemed natural for both unspecs to have the predicate. OTOH, since SVE_COND_FP_BINARY is never used independently, and since it's an unspec, I guess it doesn't matter much either way. Richard
