From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0AFA6394FC38; Thu, 17 Mar 2022 11:14:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0AFA6394FC38 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r Date: Thu, 17 Mar 2022 11:14:45 +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: 12.0 X-Bugzilla-Keywords: compile-time-hog 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: 12.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 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: Thu, 17 Mar 2022 11:14:46 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102943 --- Comment #48 from Richard Biener --- (In reply to Andrew Macleod from comment #47) > Created attachment 52637 [details] > new patch >=20 > I am working on a alternative cache for GCC 13, but along the way, I have > changes to the ranger_cache::range_from_dom() routine. The original vers= ion > gave up when it hit a block which had outgoing edges. The new version is > smarter and basically goes back until it finds a cache entry, and then > intersects all outgoing edge between the two places. It also removes the > recursion , and does not SET any cache values during the lookup (making i= t a > true query). >=20 > The net effect of this is significant improvements in cache performance > because its used far less, but there is more time spend doing calculation= s. > This bootstraps and passes all regression tests. we do miss out on a few > minor opportunities (30 out of 4400 in all of EVRP over the GCC source)=20 > which occur as a result of updated values not being propagated properly as > the cache is no longer "full" like it was before.=20=20 >=20 > IN GCC 13 I will address this, but I thought you might be interested in > trying this patch against this PR. >=20 > In building 380 GCC source files, I see the following avg speedups > evrp : -22.57% > VRP2 : -5.4% > thread_jumps_full : -14.16% > total : -0.44% >=20 > So it is not insignificant. >=20 > It is likely to be most effective in large CFGs. > This is *total* compile time percent speed up for the 5 most significant > cases: >=20 > expr.ii -2.62% > lra-constraints.ii -3.75% > caller-save.ii -3.98% > reload.ii -4.04% > optabs.ii -5.05% >=20 > EVRP isolated speedups (yes, these are *percetage* speedup) > expr.ii -62.38 > simplify-rtx.ii -65.97 > lra-constraints.ii -67.87 > reload.ii trunk -68.67 > caller-save.ii trunk -71.93 > optabs.ii trunk -78.69 >=20 > I think those times are probably worth the odd miss. >=20 > Anyway, next time you are checking performance for this PR maybe also try > this patch and see how it performs. It helps quite a bit, the worst case is now tree VRP : 5.14 ( 7%) 0.02 ( 3%) 5.15 ( = 7%) 2 9M ( 3%) backwards jump threading : 4.05 ( 6%) 0.00 ( 0%) 4.06 ( = 6%) 222 0k ( 0%) overall the patch reduces compile time from 766s to 749 (parallel compile, serial LTO, release checking). So IMHO definitely worth it if you are happy with it.=