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;
