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