https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116787
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #8) > (In reply to Richard Biener from comment #7) > > > I think the issue is that we pad out the compare RTXen with zeros but > > not the RHS when they are equal to the compare operands. We then later > > are not able to combine to maxps. > > > > Something like > > > > diff --git a/gcc/config/i386/mmx.md b/gcc/config/i386/mmx.md > > index 9a8d6030d8b..8b846306fd6 100644 > > --- a/gcc/config/i386/mmx.md > > +++ b/gcc/config/i386/mmx.md > > @@ -1184,6 +1184,14 @@ > > > > emit_insn (gen_movq_v2sf_to_sse (ops[5], operands[5])); > > emit_insn (gen_movq_v2sf_to_sse (ops[4], operands[4])); > > + if (rtx_equal_p (operands[5], operands[2])) > > + ops[2] = ops[5]; > > + else if (rtx_equal_p (operands[5], operands[1])) > > + ops[1] = ops[5]; > > + if (rtx_equal_p (operands[4], operands[1])) > > + ops[1] = ops[4]; > > + else if (rtx_equal_p (operands[4], operands[2])) > > + ops[2] = ops[4]; > > > > bool ok = ix86_expand_fp_vcond (ops); > > gcc_assert (ok); > > This is with gcc-14? Because current mainline doesn't have vcond expander > anymore. Yes, sorry - my dev tree was "busy". I agree it's more difficult to fix this on trunk where we rely on combine. But the operation with just the comparison op zeroing of the upper half isn't really a max anymore given how we model it as V4SF. Maybe vec_cond_mask could keep the native V2SFmode operation. And maybe it's not really an important case.
