A renewed look at GCC's performance from rebuild_jump_labels's view

A renewed look at GCC's performance from rebuild_jump_labels's view

[Steven Bosscher]

Hi,

Kazu reported on the performance of tree-ssa from rebuild_jump_labels's
view in March last year: http://gcc.gnu.org/ml/gcc/2004-03/msg00659.html.

I decided to redo this little experiment on my collection of cc1-i files.
My results for today's CVS head at -O2 on amd64:

  mainline today
-------------------
       calls  total
cse1     820  11686
cse2      24  11686
gcse    8705  11686
bypass   643  11686
combine   15  11686

"calls" is the number of calls to rebuild_jump_labels() right after
CSE1 (or CSE2, GCSE, BYPASS, or COMBINE).

"total" is the number of calls to the pass itself, i.e. the number of
functions that the RTL optimizers got to see.

GCSE is this high because gcse_main unconditionally returns 1 if it runs 
anything (i.e. when !is_too_expensive) which is probably a bug.  This
number does _not_ include the extra rebuild_jump_labels() call after the
re-runs of cse_main in rest_of_handle_gcse (I just used Kazu's patch and
he didn't take those into account either).

Apparently I have a larger set of .i files than Kazu had.  But still CSS2
almost never has to rebuild_jump_labels, and neither does combine.  I am
not sure why the number for CSE1 is this high.  But 820 out of 11686 is
still only 7% of the times that CSE1 needs to rebuild labels.

Gr.
Steven