https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org, | |uros at gcc dot gnu.org Status|ASSIGNED |NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- After the latest fixes we still fail to recognize min/max early for float < 0.0 ? float : 0.0 because prepare_cmp_insn doesn't push the FP 0.0 constant to a reg since RTX cost for this seems to be zero. We then call insn_operand_matches which ultimatively fails in ix86_fp_comparison_operator as ix86_fp_comparison_strategy is IX86_FPCMP_COMI here and ix86_trivial_fp_comparison_operator for (lt (reg/v:SF 110 [ t2 ]) (const_double:SF 0.0 [0x0.0p+0])) returns false. If I fix things so we try (gt (const_double:SF 0.0 [0x0.0p+0]) (reg:SF ..)) then maybe_legitimize_operands "breaks" things here since it forces the cond operand to a register but not the comparison operand so ix86_expand_fp_movcc again FAILs. I'm not sure why the x86 backend allows any CONST_DOUBLE as part of comparisons (during expansion only?). This and maybe special-handling of rtx_cost with this special constant and LT/GT code makes the first compares not recognized as MIN/MAX. The rest is fixed now. Patch for trying (gt ..): diff --git a/gcc/optabs.cc b/gcc/optabs.cc index 32ff379ffc3..3ff8ba88bbb 100644 --- a/gcc/optabs.cc +++ b/gcc/optabs.cc @@ -4607,6 +4607,14 @@ prepare_cmp_insn (rtx x, rtx y, enum rtx_code comparison, rtx size, break; } + if (FLOAT_MODE_P (mode)) + { + prepare_cmp_insn (y, x, swap_condition (comparison), + size, unsignedp, methods, ptest, pmode); + if (*ptest) + return; + } + if (methods != OPTAB_LIB_WIDEN) goto fail;