This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
A renewed look at GCC's performance from rebuild_jump_labels's view
- From: Steven Bosscher <stevenb at suse dot de>
- To: gcc at gcc dot gnu dot org
- Cc: Kazu Hirata <kazu at codesourcery dot com>
- Date: Sat, 4 Jun 2005 18:06:56 +0200
- Subject: A renewed look at GCC's performance from rebuild_jump_labels's view
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