RFC/RFHelp: overhaul C front end's identifier->decl lookup
Michael Matz
matz@suse.de
Fri Apr 4 16:06:00 GMT 2003
Hi,
On Thu, 3 Apr 2003, Zack Weinberg wrote:
> which I will look at tomorrow when I am awake. But what I need help
> with is, c-symbol-lookup.diff accomplishes a small speedup, but
> c-tag-lookup.diff makes the compiler slower than it was before I
> began, and I don't understand why.
OK, I now changed the diffs to be applyable and tried a profilable version
of the compiler on a big C testcase (basically a concatenation of
insn-attrtab.c, insn-recog.c, expr.c and fold-const.c).
normal HEAD:
% time ./cc1no-zack -quiet big.i
real 0m49.101s
user 0m48.200s
sys 0m0.840s
% gprof -b ./cc1no-zack | head -n 20 | tail -n 16
time seconds seconds calls ms/call ms/call name
5.82 1.81 1.81 286380 0.01 0.01 record_reg_classes
5.05 3.38 1.57 2068 0.76 1.10 verify_flow_info
4.41 4.75 1.37 1967762 0.00 0.00 invalid_mode_change_p
2.90 5.65 0.90 1526257 0.00 0.00 for_each_rtx
2.38 6.39 0.74 439619 0.00 0.00 find_reloads
1.87 6.97 0.58 1 580.00 30872.43 yyparse
1.61 7.47 0.50 6159 0.08 0.11 subst_reloads
1.48 7.93 0.46 5590254 0.00 0.00 ggc_alloc
1.48 8.39 0.46 2596854 0.00 0.00 copy_rtx_if_shared
1.48 8.85 0.46 2255629 0.00 0.00 extract_insn
1.45 9.30 0.45 1142316 0.00 0.00 propagate_one_insn
1.38 9.73 0.43 1701921 0.00 0.00 bitmap_operation
1.06 10.06 0.33 3070902 0.00 0.00 mark_set_1
1.03 10.38 0.32 141 2.27 2.27 sbitmap_vector_alloc
0.90 10.66 0.28 577031 0.00 0.00 reg_scan_mark_refs
and the final time in seconds was 31.08
with out two patches:
% time ./cc1zack -quiet big.i
real 0m48.739s
user 0m47.830s
sys 0m0.890s
% gprof -b ./cc1zack | head -n 20 | tail -n 16
time seconds seconds calls ms/call ms/call name
7.03 2.14 2.14 286380 0.01 0.01 record_reg_classes
4.99 3.66 1.52 2068 0.74 1.05 verify_flow_info
2.92 4.55 0.89 1526257 0.00 0.00 for_each_rtx
2.79 5.40 0.85 439619 0.00 0.00 find_reloads
2.56 6.18 0.78 1967762 0.00 0.00 invalid_mode_change_p
2.20 6.85 0.67 2255629 0.00 0.00 extract_insn
1.91 7.43 0.58 1142316 0.00 0.00 propagate_one_insn
1.91 8.01 0.58 6159 0.09 0.11 subst_reloads
1.77 8.55 0.54 5590197 0.00 0.00 ggc_alloc
1.74 9.08 0.53 1 530.00 30289.12 yyparse
1.61 9.57 0.49 1701921 0.00 0.00 bitmap_operation
1.41 10.00 0.43 2596854 0.00 0.00 copy_rtx_if_shared
1.18 10.36 0.36 3070902 0.00 0.00 mark_set_1
1.02 10.67 0.31 141 2.20 2.20 sbitmap_vector_alloc
0.99 10.97 0.30 577031 0.00 0.00 reg_scan_mark_refs
the final time in seconds is 30.44
I.e. all in all I think this patch has no real performance impact either
way, at least not in a profiling cc1.
I also tried an optimized cc1, and the results are similar:
% time ./cc1no-zack-O2 -quiet big.i
real 0m20.825s
user 0m20.070s
sys 0m0.750s
% ./cc1zack-O2 -quiet big.i
real 0m20.640s
user 0m19.860s
sys 0m0.790s
> this is all on an otherwise idle 2GHz P4 laptop with 512MB of RAM.
And this was a 1.8Ghz Athlon with 512MB.
Ciao,
Michael.
More information about the Gcc-patches
mailing list