cfg_cleanup speedup

[Jan Hubicka]

> It reduces it somewhat, but not a lot:
> 
>  cfg cleanup           :  28.74 (18%) usr   0.00 ( 0%) sys  28.81 (18%) wall
>  ...
>  TOTAL                 : 155.48             4.34           160.00

Hi,
I am not quite sure that it is the case of your testcase, but if I construct
the heavilly crossjumpable flowgraph (in my testcase an full decision tree
with same leaf nodes), the cfg_cleanup takes a while to crossjump the whole
thing.  With the -O2 the time is stll not dominant (as cse of instance
takes ages too) and I believe collapsing the CFG woths it, but for -O1 it is
probably not good idea.

If you manage to get the code crossjumpable even in the old jump.c
implementation it takes about 4 times more, so it is not so big problem
of the crossjumping implementation even when there are some places to improve.


Sat Oct 20 13:30:20 CEST 2001  Jan Hubicka  <jh@suse.cz>

	* cfgcleanup.c (try_optimize_cfg): Limit number of iterations unless
	flag_expensive_optimizations is used.

Index: cfgcleanup.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/cfgcleanup.c,v
retrieving revision 1.9
diff -c -3 -p -r1.9 cfgcleanup.c
*** cfgcleanup.c	2001/10/10 11:33:05	1.9
--- cfgcleanup.c	2001/10/20 11:29:33
*************** try_optimize_cfg (mode)
*** 1061,1066 ****
--- 1061,1072 ----
        changed = false;
        iterations++;
  
+       /* Limit the number of iterations unless we are donig expensive
+          optimizations as the number may get large for heavilly crossjumpable
+ 	 programs.  */
+       if (!flag_expensive_optimizations && iterations > 5)
+ 	break;
+ 
        if (rtl_dump_file)
  	fprintf (rtl_dump_file, "\n\ntry_optimize_cfg iteration %i\n\n",
  		 iterations);