This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Some aspect of GCC memory consumption increased by recent patch


Hi,
Comparing memory consumption on compilation of combine.i and generate-3.4.ii I got:


comparing combine.c compilation at -O0 level:
    Overall memory needed: 25000k
    Peak memory use before GGC: 9434k -> 9433k
    Peak memory use after GGC: 8746k
    Maximum of released memory in single GGC run: 2798k -> 2796k
    Garbage: 42297k -> 42290k
    Leak: 6479k -> 6463k
    Overhead: 5872k -> 5871k
    GGC runs: 327

comparing combine.c compilation at -O1 level:
    Overall memory needed: 27400k -> 27416k
    Peak memory use before GGC: 8961k -> 8959k
    Peak memory use after GGC: 8543k
    Maximum of released memory in single GGC run: 2228k -> 2227k
    Garbage: 63055k -> 63030k
    Leak: 6839k
    Overhead: 7600k -> 7599k
    GGC runs: 519

comparing combine.c compilation at -O2 level:
    Overall memory needed: 19892k
    Peak memory use before GGC: 12790k
    Peak memory use after GGC: 12534k
    Maximum of released memory in single GGC run: 2624k
    Garbage: 87676k -> 87655k
    Leak: 6654k
    Overhead: 10938k -> 10937k
    GGC runs: 536

comparing combine.c compilation at -O3 level:
    Overall memory needed: 22424k -> 22588k
    Peak memory use before GGC: 14396k
    Peak memory use after GGC: 12941k
    Maximum of released memory in single GGC run: 3073k
    Garbage: 122068k -> 122063k
    Leak: 7117k
    Overhead: 15065k -> 15068k
    GGC runs: 610

comparing insn-attrtab.c compilation at -O0 level:
  Amount of produced GGC garbage increased from 154411k to 154651k, overall 0.16%
    Overall memory needed: 85872k
    Peak memory use before GGC: 74238k -> 74237k
    Peak memory use after GGC: 45259k -> 45258k
    Maximum of released memory in single GGC run: 38092k
    Garbage: 154411k -> 154651k
    Leak: 11423k -> 11183k
    Overhead: 19887k -> 19887k
    GGC runs: 267 -> 268

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 103284k -> 103036k
    Peak memory use before GGC: 81336k -> 81342k
    Peak memory use after GGC: 66510k -> 66516k
    Maximum of released memory in single GGC run: 35976k -> 35984k
    Garbage: 307315k -> 307434k
    Leak: 11466k -> 11475k
    Overhead: 37567k -> 37576k
    GGC runs: 385

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 140456k -> 140880k
    Peak memory use before GGC: 107782k -> 107783k
    Peak memory use after GGC: 82775k -> 82777k
    Maximum of released memory in single GGC run: 35344k -> 35350k
    Garbage: 403821k -> 404106k
    Leak: 11434k -> 11444k
    Overhead: 50431k -> 50480k
    GGC runs: 336 -> 335

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 140496k -> 140912k
    Peak memory use before GGC: 107783k
    Peak memory use after GGC: 82778k -> 82776k
    Maximum of released memory in single GGC run: 35344k -> 35350k
    Garbage: 404598k -> 404881k
    Leak: 11457k -> 11467k
    Overhead: 50552k -> 50600k
    GGC runs: 343 -> 342

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 112060k -> 111864k
    Peak memory use before GGC: 87417k -> 87277k
    Peak memory use after GGC: 86002k -> 85812k
    Maximum of released memory in single GGC run: 20638k -> 20589k
    Garbage: 247927k -> 246714k
    Leak: 53802k -> 53800k
    Overhead: 43074k -> 43019k
    GGC runs: 372 -> 370

comparing Gerald's testcase PR8361 compilation at -O1 level:
  Amount of produced GGC garbage decreased from 598898k to 565212k, overall -5.96%
    Overall memory needed: 94624k -> 94460k
    Peak memory use before GGC: 86531k -> 86367k
    Peak memory use after GGC: 85006k -> 84842k
    Maximum of released memory in single GGC run: 20329k -> 20256k
    Garbage: 598898k -> 565212k
    Leak: 57906k -> 57250k
    Overhead: 75697k -> 71877k
    GGC runs: 620 -> 613

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Amount of produced GGC garbage decreased from 704181k to 659941k, overall -6.70%
    Overall memory needed: 95416k -> 94440k
    Peak memory use before GGC: 86532k -> 86367k
    Peak memory use after GGC: 85006k -> 84842k
    Maximum of released memory in single GGC run: 20329k -> 20255k
    Garbage: 704181k -> 659941k
    Leak: 58791k -> 58077k
    Overhead: 94499k -> 90267k
    GGC runs: 746 -> 707

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 95808k -> 95616k
    Peak memory use before GGC: 87454k -> 87290k
    Peak memory use after GGC: 86288k -> 86123k
    Maximum of released memory in single GGC run: 20589k -> 20516k
    Garbage: 680685k -> 679564k
    Leak: 58921k -> 58856k
    Overhead: 93317k -> 93012k
    GGC runs: 709 -> 707

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-05-14 13:52:30.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-05-15 02:23:47.000000000 +0000
@@ -1,3 +1,70 @@
+2005-05-14  Kaz Kojima  <kkojima@gcc.gnu.org>
+
+	* config/sh/sh.c (sh_output_mi_thunk): Check cfun->cfg instead
+	of basic_block_info.  Call init_flow and find_basic_blocks
+	before dbr_schedule if needed.
+
+2005-05-14  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* tree-optimize.c (init_tree_optimization_passes): Move
+	pass_cd_dce in place of the last pass_dce.
+
+	PR tree-optimization/21563
+	* tree-vrp.c (compare_value): Return boolean_false_node when
+	SSA_NAME in "if (SSA_NAME == CST)" is strictly smaller than or
+	strictly larger than CST.
+
+2005-05-14  Nathan Sidwell  <nathan@codesourcery.com>
+	    Jan-Benedict Glaw  <jbglaw@lug-owl.de>
+
+	* config/vax/vax.c: (print_operand_address) Use gcc_unreachable() and
+	gcc_assert().
+	(rev_cond_name) Likewise.
+	(vax_float_literal) Likewise.
+	* config/vax/vax.md: Likewise.
+
+2005-05-14  Jan-Benedict Glaw  <jbglaw@lug-owl.de>
+
+	* config/vax/vax.md: define_constant VAXens AP, FP, SP and PC
+	registers and use them (specifically the stack pointer).
+	* config/vax/vax.h: Use above defines right here.
+
+	* config/vax/vax.c: (override_options) Remove 'register' keyword.
+	(split_quadword_operands) Likewise. (rev_cond_name) Likewise.
+	(vax_float_literal) Likewise. (vax_rtx_costs) Remove trailing
+	whitespace.
+	* config/vax/vax.h: Remove 'register' keyword. Misc. whitespace fixes,
+	mostly removal of trailing spaces...
+	* config/vax/vax-modes.def: Remove trailing whitespace.
+
+	* config/vax/elf.h: Update whitespace.
+
+2005-05-14  Richard Guenther  <rguenth@gcc.gnu.org>
+
+	Revert
+	2005-05-11  Richard Guenther  <rguenth@gcc.gnu.org>
+	* fold-const.c (fold_indirect_ref_1): Avoid removing
+	NOP_EXPRs with type qualifiers like const.
+
+2005-05-14  Jan Hubicka  <jh@suse.cz>
+
+	Patch by Richard Henderson:
+	* tree-eh.c (tree_can_throw_internal, tree_can_throw_external):
+	Handle RESX expressions properly.
+
+	* tree-eh.c (record_stmt_eh_region): Use add_stmt_to_eh_region.
+	(add_stmt_to_eh_region_fn): Nest into CALL_EXPR.
+	(remove_stmt_from_eh_region_fn): Likewise.
+
+	* tree-cfg.c (execute_warn_function_return): Break out noreturn
+	warning too..
+	(execute_warn_function_noreturn): ... here.
+	(pass_warn_function_noreturn): New pass.
+	* tree-pass.h (pass_warn_function_noreturn): Declare
+	* tree-optimize.c (init_tree_optimization_passes): Move return
+	warnings early and add noreturn warnings at place of previous
+	return warnings.
+
 2005-05-14  Kazu Hirata  <kazu@cs.umass.edu>
 
 	* tree-ssa-live.c (tpa_init, tpa_delete, tpa_compact,

I am friendly script caring about memory consumption in GCC.  Please contact
jh@suse.cz if something is going wrong.

The results can be reproduced by building compiler with
--enable-gather-detailed-mem-stats targetting x86-64 and compiling preprocessed
combine.c or testcase from PR8632 with:

-fmem-report --param=ggc-min-heapsize=1024 --param=ggc-min-expand=1 -Ox -Q

The memory consumption summary appears in the dump after detailed listing of
the places they are allocated in.  Peak memory consumption is actually computed
by looking for maximal value in {GC XXXX -> YYYY} report.

Yours testing script.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]