From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id D15B6385840B; Tue, 21 May 2024 07:31:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D15B6385840B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1716276700; bh=TV6FoJaxPQ1wQGy062YdkdGU+qvXeGq1I3KnUSU1sCY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=gj8kINiOD9c5Yb/qhlMZnWaEHahdz1OnEERUf9/Rgy9Q6JvZvtWeqmcF0p0JkFNTy sjmWAwDrK0Y+zZjWH0QIt4hd0JIJp67Lr5lzKd0+O6+Rp7tdYSgsiYxSle8pSZ5pin Fq/BAl8lYKeJv5bhrMj+PXlDIA1DGdCe0G7y4OiY= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095 Date: Tue, 21 May 2024 07:31:37 +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: 15.0 X-Bugzilla-Keywords: missed-optimization, testsuite-fail X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 15.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D115144 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at gcc dot gnu.org --- Comment #6 from Richard Biener --- For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the exit= (0) call with a return 0 statement? Looking at gcc.target/cris/pr93372-47.c what we do here is sink tot_bits += =3D n_bits into the else { of the in-loop conditional, in particular we sink it right before the exit conditional in the loop. That's exactly what we are supposed to do and the previous heuristic avoided because of the guessed profile which is if (n_bits_12 =3D=3D 0) goto ; [5.50%] else goto ; [94.50%] thus the n_bits =3D=3D 0 exit is unlikely and for some reason we thought sinking across that isn't profitable. To quote the loop in question is: for (;;) { ran =3D simple_rand (); n_bits =3D (ran >> 1) % 16; tot_bits +=3D n_bits; if (n_bits =3D=3D 0) return x; else { x <<=3D n_bits; if (ran & 1) x |=3D (1 << n_bits) - 1; if (tot_bits > 8 * sizeof (long long) + 6) return x; } } Note that the sinking doesn't increase register lifetime (one of the reasons of the previous heuristic), esp. if we'd go one step further and sink to the start of the else { block rather than right before the exit conditional. But I'd guess that wouldn't help the delay-slot filling here? I've noticed CRIS doesn't support scheduling at all, so delay slot filling (where's that done?) relies purely on our "random" scheduling we do at RTL expansion time (via TER) and during GIMPLE optimization? That said, I think sinking now works as expected. I do want to play with sinking to the start of the else {, but without doing any lifetime analysis I fear that's going to be worse in the average as the current location at least ensures we're close to the first use of the DEF we sink.=