Bug 28614 - gcc.c-torture/compile/20001226-1.c times out
Summary: gcc.c-torture/compile/20001226-1.c times out
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
Depends on:
Blocks:
 
Reported: 2006-08-05 21:25 UTC by John David Anglin
Modified: 2023-02-13 14:57 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John David Anglin 2006-08-05 21:25:34 UTC
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)
Comment 1 dave 2006-08-05 21:29:16 UTC
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
Comment 2 Steve Ellcey 2008-12-05 17:05:54 UTC
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

Comment 3 Steve Ellcey 2008-12-05 17:16:56 UTC
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.
Comment 4 dave 2008-12-05 20:42:23 UTC
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
Comment 5 Richard Biener 2023-02-06 12:31:37 UTC
FRE seems to take most of the time on this testcase.
Comment 6 GCC Commits 2023-02-13 14:57:37 UTC
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.