Re: C++ optimization: compile time + memory consumption regressionon gcc3.3 branch

[Karel Gardas <kgardas at objectsecurity dot com>]

On Mon, 3 Mar 2003, Karel Gardas wrote:

> > Before and after means simply once with a checkout of the fast version,
> > and once with the slow one.  So you can identify the bottleneck.  In your
> > case expand needs excessively long, so I guess simply looking at the
> > profile of that one is enough to see the bottleneck.
>
> Yes, I hope profiling of gcc3.2.2 will be useless. I have whole output of
> gprof compressed on my disc so if anyone is interested I can provide it on
> direct request (~300kB bzip2 compressed file). Now I'll try to binary
> search gcc-3_3-branch to find the problematic patch. Anyway if you find
> the problematic patch by looking into gprof output above, please let me
> know to save my time.

I've tried profile build of main trunk too (since it seems to suffer from
the same problem) and gprof output looks very similar:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 31.66    226.75   226.75 426657608     0.00     0.00  fixup_var_refs_1
 30.38    444.27   217.52   114871     0.00     0.00  fixup_var_refs_insns
 13.10    538.05    93.78 426657616     0.00     0.00  fixup_var_refs_insn
  4.45    569.91    31.86 145356023     0.00     0.00  reg_mentioned_p
  2.26    586.12    16.21    11836     0.00     0.00  fixup_var_refs
  1.52    597.04    10.92 148255705     0.00     0.00  rtx_equal_p
  0.56    601.03     3.99    34094     0.00     0.00  clear_table
  0.49    604.53     3.50  1146133     0.00     0.00  walk_tree
  0.45    607.73     3.20 41906215     0.00     0.00  walk_fixup_memory_subreg
  0.42    610.72     2.99 22755697     0.00     0.00  ggc_alloc
  0.40    613.55     2.83   894745     0.00     0.00  gt_ggc_mx_lang_tree_node
  0.36    616.12     2.57    72757     0.00     0.00  htab_traverse
  0.31    618.34     2.22     2598     0.00     0.00  init_alias_analysis
  0.30    620.46     2.12 26647652     0.00     0.00  ggc_set_mark
  0.29    622.52     2.06   107169     0.00     0.00  alloc_page
  0.25    624.31     1.79      536     0.00     0.00  loop_regs_scan
  0.24    626.01     1.70  1089280     0.00     0.00  emit_insn
  0.21    627.49     1.48   160240     0.00     0.00  sbitmap_union_of_diff_cg
  0.20    628.89     1.40 62216779     0.00     0.00  bitmap_find_bit
  0.20    630.29     1.40    73592     0.00     0.00  record_reg_classes
  0.19    631.62     1.33 31859625     0.00     0.00  bitmap_set_bit
  0.18    632.89     1.27 10709363     0.00     0.00  single_set_2
  0.18    634.16     1.27  6626993     0.00     0.00  htab_find_slot_with_hash
  0.17    635.39     1.23     2192     0.00     0.00  scan_loop
  0.17    636.60     1.21   930630     0.00     0.00  expand_expr
  0.15    637.70     1.10  6912798     0.00     0.00  copy_node
  0.14    638.71     1.01   288319     0.00     0.00  flow_delete_block_noexpunge
  0.14    639.71     1.00 14739345     0.00     0.00  mark_local_for_remap_r
  0.14    640.70     0.99 27296096     0.00     0.00  lookup_page_table_entry
  0.13    641.63     0.93      806     0.00     0.00  ggc_pop_context
  0.12    642.47     0.84  6930456     0.00     0.00  comptypes
  0.12    643.30     0.83   287560     0.00     0.00  cse_insn
  0.11    644.11     0.81  1467787     0.00     0.00  for_each_rtx
  0.11    644.90     0.79 12028472     0.00     0.00  find_reg_note
  0.11    645.67     0.77  1980125     0.00     0.00  splay_tree_splay_helper
  0.11    646.43     0.76    26682     0.00     0.00  compute_transp
  0.10    647.18     0.75 18251738     0.00     0.00  add_insn
  0.10    647.92     0.74 30730859     0.00     0.00  statement_code_p
  0.10    648.63     0.71     4813     0.00     0.00  allocate_reg_info
  0.09    649.31     0.68   843991     0.00     0.00  count_reg_usage


I've used the same options like in case of gcc33 branch. Sources are from
3.4 20030226 (experimental) version.

So perhaps the problem was introduced after creation of gcc-3_2-branch and
so I should try binary search between gcc-3_2-branchpoint and
gcc-3_3-branchpoint. Right?

Thanks,

Karel
--
Karel Gardas                  kgardas at objectsecurity dot com
ObjectSecurity Ltd.           http://www.objectsecurity.com