This test is failing more often, so I thought I would bring back a PR. On hppa2.0w-hp-hpux11.11 (dual 750 MHz, 8 GB memory): WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O2 (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -fomit-frame-pointer (test for ex cess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -O3 -g (test for excess errors) WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c -Os (test for excess errors) On i686-pc-linux-gnu (2 GHz, 1GB memory): WARNING: program timed out. FAIL: gcc.c-torture/compile/20001226-1.c (test for excess errors)
Subject: Re: New: gcc.c-torture/compile/20001226-1.c times out > On i686-pc-linux-gnu (2 GHz, 1GB memory): Oops, that should have been 3.2 GHz. Dave
Subject: Bug 28614 Author: sje Date: Fri Dec 5 17:04:27 2008 New Revision: 142485 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142485 Log: PR other/28614 * gcc.c-torture/compile/20001226-1.c: Add dg-timeout-factor. * g++.dg/torture/pr31863.C: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr31863.C trunk/gcc/testsuite/gcc.c-torture/compile/20001226-1.c
Dave, I added a dg-timeout-factor to this test for HPPA so it shouldn't time out on PA boxes anymore. I hadn't noticed the x86 timeout part of the report when I first looked at it. Do you still have that problem? If so we can change the test to increase the timeout there too or, if you don't have that problem anymore we can just close this bug out since it should be fixed on PA now.
Subject: Re: gcc.c-torture/compile/20001226-1.c times out > ------- Comment #3 from sje at cup dot hp dot com 2008-12-05 17:16 ------- > Dave, I added a dg-timeout-factor to this test for HPPA so it shouldn't time > out on PA boxes anymore. I hadn't noticed the x86 timeout part of the report > when I first looked at it. Do you still have that problem? If so we can > change the test to increase the timeout there too or, if you don't have that > problem anymore we can just close this bug out since it should be fixed on PA > now. I haven't done a GCC build recently on this x86 system but I don't believe there is a timeout problem with this test on most x86 systems. Instead of just arbitrarily increasing the timeout values, I tend to think timeout values should be scaled based on the time for some base compilation. It also would be nice to keep execution time records for certain benchmark tests to that it might be possible to detect regressions in compilation speed. Dave
FRE seems to take most of the time on this testcase.
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1 commit r13-5966-g72ae1e5635648bd3f6a5760ca46d531ad1f2c6b1 Author: Richard Biener <rguenther@suse.de> Date: Mon Feb 13 14:41:24 2023 +0100 tree-optimization/28614 - high FRE time for gcc.c-torture/compile/20001226-1.c I noticed that for gcc.c-torture/compile/20001226-1.c even -O1 has around 50% of the compile-time accounted to FRE. That's because we have blocks with a high incoming edge count and can_track_predicate_on_edge visits all of them even though it could stop after the second. The function is also called repeatedly for the same edge. The following fixes this and reduces the FRE time to 1% on the testcase. PR tree-optimization/28614 * tree-ssa-sccvn.cc (can_track_predicate_on_edge): Avoid walking all edges in most cases. (vn_nary_op_insert_pieces_predicated): Avoid repeated calls to can_track_predicate_on_edge unless checking is enabled. (process_bb): Instead call it once here for each edge we register possibly multiple predicates on.