From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D9B803858435; Mon, 15 Aug 2022 08:55:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D9B803858435 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/106617] [13 Regression] gcc is very slow at ternary expressions, Date: Mon, 15 Aug 2022 08:55:05 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: compile-time-hog, needs-bisection 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: 13.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc bug_status cf_reconfirmed_on keywords everconfirmed 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2022 08:55:06 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106617 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed| |2022-08-15 Keywords| |needs-bisection Ever confirmed|0 |1 --- Comment #7 from Richard Biener --- Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 Applying pattern match.pd:5769, generic-match.cc:14472 ... that's the following pattern which GCC 12 doesn't have /* From fold_binary_op_with_conditional_arg handle the case of rewriting (a ? b : c) > d to a ? (b > d) : (c > d) when the compares simplify. */ (for cmp (simple_comparison) (simplify (cmp:c (cond @0 @1 @2) @3) /* Do not move possibly trapping operations into the conditional as this pessimizes code and causes gimplification issues when applied late. */ (if (!FLOAT_TYPE_P (TREE_TYPE (@3)) || operation_could_trap_p (cmp, true, false, @3)) (cond @0 (cmp! @1 @3) (cmp! @2 @3))))) the testcase is essentially a degenerate case of this, applying the pattern recursively. The testcase is a bit too large to easily follow what happens, cutting some lines in the middle shows we are eventually producing 0, 0 ? nr_cpu_ids =3D=3D 0 && ((nr_cpu_ids & 7) =3D=3D 0 && (nr_cpu_ids = =3D=3D 0 && ((nr_cpu_ids & 5) =3D=3D 0 && (nr_cpu_ids =3D=3D 0 && ((nr_cpu_ids & 3) =3D= =3D 0 && (nr_cpu_ids + -1 & 1) !=3D 0))))) : 0 ? 2 : 1; not sure why we don't fold the (0, 0) ? ..., that seems to be a "bug" of fully folding in the C frontend? We do simplify 0 ? ... just fine. Supposedly COMPOUND_EXPRs are never constant folded?=