From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C222E3858C60; Wed, 22 May 2024 01:15:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C222E3858C60 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1716340553; bh=SEkDOprBleBdm3jBwJopVUzvAMyYGrEUyHIsbtaRQTQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YpHw1uPt2jGtI8CWrK0niKc3YyhoyEv4v9Dc+lnMPyg4GRvJIbRkO6Dr78+ZMDrdz bYh4kn0RgnbKAFsSoI7eHRlC158qIHwEfnNzVAJqQc/Rz9mfBhg7KcAxyCfE/QseP1 9S5knH6prLap35UYT5jbbWjTzD98utDGYzf+wGL8= From: "hp 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: Wed, 22 May 2024 01:15:52 +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: hp 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: 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 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Richard Biener from comment #6) > For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the ex= it > (0) call with a return 0 statement? No. FWIW, it also doesn't help renaming and wrapping main to xmain __attribute__ noipa. > 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[...] Yes; see previous comments. I'd say the changes in random_bitstring are no longer "interesting". I've also analyzed the unfilled delay-slot signalled= by gcc.target/cris/pr93372-47.c to be because of a bug in that pass. (Not the same, but events are amusingly parallel to the bug that made me add that test-case.) > Note that the sinking doesn't increase register lifetime (one of the reas= ons > 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 her= e? Sorry, I don't follow here, but I'm going to let that be, as random_bitstri= ng isn't interesting (except regarding the bug). > 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? Delay-slot-filling is unrelated to scheduling. It's in reorg.cc with its o= wn horribly outdated dataflow analysis in resource.cc (but used to be shared). > That said, I think sinking now works as expected. In random_bitstring I agree, but there's fallout in main. > I do want to play with > sinking to the start of the else {, but without doing any lifetime analys= is > 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. Thank you in advance and for the look this far! I haven't looked closer at what happens with later passes in main, but looking at the generated assemb= ly code, the "sinking" of a division has the eventual effect of increasing register pressure; see the previously attached dumps.=