From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7C9D03858C53; Fri, 21 Jul 2023 08:18:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7C9D03858C53 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1689927483; bh=fPadZXdyjZyN7ivxpdARgAZVaQIRdl2Lq3+WJJzDDC0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iYLPxuLWE4kc/6+TYlZezKTw1R07XUHnpmKnFgaaPOl+czFzwkPOvKabLn2Eq3uUC 9zhKlacR73vQxjNCz07Qj06eqOn0dR1Dvlr/TnLI0GNDiqdWolyXyhSTz/BVp0qkf2 JR4mJnFpIO0o1uAYlQ1YGgg6OJVxaBCSNqbpG4KQ= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/106952] Missed optimization: x < y ? x : y not lowered to minss Date: Fri, 21 Jul 2023 08:18:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106952 Richard Biener 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 d= ot gnu.org --- Comment #5 from Richard Biener --- 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 !=3D OPTAB_LIB_WIDEN) goto fail;=