This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch] Fix for PR middle-end/38059, Compile time regression

Steve Ellcey wrote:
The test gcc.dg/20020425-1.c compiles in less then 1 second on my IA64
box using GCC 4.3.1 but takes 50+ seconds using the ToT GCC.

In examining the compilation slowdown of this test I found that all the
time was being spent in the 'useless' pass of GCC which is supposed to
be a quick pass to throw out obviously useless code so that the rest
of the compiler doesn't have to analyze it and can run quicker.

20020425-1.c is a worst case test for this pass consisting of:

if (0) {} else if (0) {} else if (0) {} ..... 11,000 times....

useless is changing all of the if's into 'goto else-label' which
is fine but then we wind up with this (simplified) code:

goto L1; goto L2; goto L3; L3; L2; L1

but instead of 3 goto's and label's we have thousands.

The useless pass makes a complete pass of this routine, finds the
innermost 'goto L3; L3:' and removes it, then because it made a change,
it does a complete second pass through the routine and removes 'goto L2;'.
Having made another change it does a third pass, etc, removing 1 goto
in each complete pass through the routine.

This is highly inefficient and is causing the huge compile time slowdown
for the test.  On my slow HPPA box it takes long enough to time out in
the testsuite.

While it would be possible to do this optimization more efficiently,
I decided to first see what would happen if we just removed it.

Removing it gave me the same generated code as before both on this test
and on some GCC source files I compiled because the goto optimization
being done by the useless pass was now being done by the cfg pass and
I got exactly the same code as before (modulo a few label name changes).

20020425-1.c compiles in less then 5 seconds with this change instead
of taking more then 50 seconds and the compilation speed of 'real'
files did not change much at all (+/- 0.5%) with or without optimization
turned on.

Given this I think that just removing the optimization makes more sense
then trying to re-implementing it in a more efficient manner.

The following patch was tested on IA64 HP-UX and Linux and resulted in
no regressions.

OK to checkin?

2008-11-21 Steve Ellcey <>

PR middle-end/38059
* tree-cfg.c (struct rus_data): Remove has_label, last_was_goto,
last_goto_gsi fields.
(remove_useless_stmts_cond): Remove last_goto_gsi, last_was_goto.
(remove_useless_stmts_tf): Remove last_was_goto.
(remove_useless_stmts_tc): Ditto.
(remove_useless_stmts_goto): Remove.
(remove_useless_stmts_label): Remove.
(remove_useless_stmts_1): Remove GIMPLE_LABEL case, change
GIMPLE_GOTO case, remove last_was_goto.
FWIW, that pass was introduced when we still had scopes and a variety of cruft at the end of the tree optimizers which actually did affect code generation. I wouldn't be at all surprised if the pass is totally unnecessary these days. I'll support removal if someone goes through and verifies removal of the pass has little effect on a reasonable body of code (say gcc itself).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]