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

[Jeff Law]

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  <sje@cup.hp.com>
>
> 	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).