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]

GCC memory consumption decreased 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: 24113k
    Peak memory use before GGC: 9295k
    Peak memory use after GGC: 8606k
    Maximum of released memory in single GGC run: 2870k
    Garbage: 42610k
    Leak: 6105k
    Overhead: 5587k
    GGC runs: 364

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25569k -> 25561k
    Peak memory use before GGC: 9503k -> 9375k
    Peak memory use after GGC: 8797k
    Maximum of released memory in single GGC run: 2031k -> 2030k
    Garbage: 70125k -> 68500k
    Leak: 6671k
    Overhead: 11455k -> 11039k
    GGC runs: 583 -> 578

comparing combine.c compilation at -O2 level:
    Overall memory needed: 28869k -> 28893k
    Peak memory use before GGC: 12771k
    Peak memory use after GGC: 12612k
    Maximum of released memory in single GGC run: 2521k
    Garbage: 85260k -> 83588k
    Leak: 6425k
    Overhead: 15945k -> 15582k
    GGC runs: 576 -> 572

comparing combine.c compilation at -O3 level:
    Overall memory needed: 20552k -> 20560k
    Peak memory use before GGC: 13031k -> 13015k
    Peak memory use after GGC: 12692k
    Maximum of released memory in single GGC run: 3360k
    Garbage: 113136k -> 111204k
    Leak: 6927k
    Overhead: 20981k -> 20610k
    GGC runs: 641 -> 639

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 116476k
    Peak memory use before GGC: 77100k
    Peak memory use after GGC: 45185k
    Maximum of released memory in single GGC run: 42129k
    Garbage: 159513k
    Leak: 10643k
    Overhead: 19805k
    GGC runs: 310

comparing insn-attrtab.c compilation at -O1 level:
  Amount of produced GGC garbage decreased from 469324k to 451791k, overall -3.88%
    Overall memory needed: 132940k -> 132896k
    Peak memory use before GGC: 95208k -> 93160k
    Peak memory use after GGC: 71527k
    Maximum of released memory in single GGC run: 41234k
    Garbage: 469324k -> 451791k
    Leak: 11076k
    Overhead: 78042k -> 73565k
    GGC runs: 463 -> 462

comparing insn-attrtab.c compilation at -O2 level:
  Amount of produced GGC garbage decreased from 521877k to 504325k, overall -3.48%
    Overall memory needed: 207020k -> 207036k
    Peak memory use before GGC: 110768k -> 108720k
    Peak memory use after GGC: 87087k
    Maximum of released memory in single GGC run: 35979k
    Garbage: 521877k -> 504325k
    Leak: 11209k
    Overhead: 88151k -> 83674k
    GGC runs: 386 -> 384

comparing insn-attrtab.c compilation at -O3 level:
  Amount of produced GGC garbage decreased from 522970k to 505418k, overall -3.47%
    Overall memory needed: 207020k -> 207012k
    Peak memory use before GGC: 110773k -> 108725k
    Peak memory use after GGC: 87092k
    Maximum of released memory in single GGC run: 35979k
    Garbage: 522970k -> 505418k
    Leak: 11255k
    Overhead: 88546k -> 84067k
    GGC runs: 393

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 115380k
    Peak memory use before GGC: 92257k
    Peak memory use after GGC: 90051k
    Maximum of released memory in single GGC run: 20148k
    Garbage: 269110k
    Leak: 60280k
    Overhead: 47207k
    GGC runs: 383

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 108668k -> 108500k
    Peak memory use before GGC: 95715k
    Peak memory use after GGC: 88917k
    Maximum of released memory in single GGC run: 19546k
    Garbage: 605501k -> 588458k
    Leak: 62412k -> 62422k
    Overhead: 134830k -> 131163k
    GGC runs: 617 -> 604

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 109728k -> 109592k
    Peak memory use before GGC: 95715k
    Peak memory use after GGC: 88918k
    Maximum of released memory in single GGC run: 19545k
    Garbage: 661869k -> 642223k
    Leak: 62983k -> 62985k
    Overhead: 159264k -> 154633k
    GGC runs: 649 -> 640

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Amount of produced GGC garbage decreased from 696554k to 673771k, overall -3.38%
    Overall memory needed: 107828k -> 107472k
    Peak memory use before GGC: 91958k -> 91702k
    Peak memory use after GGC: 90400k
    Maximum of released memory in single GGC run: 20260k
    Garbage: 696554k -> 673771k
    Leak: 63375k
    Overhead: 169003k -> 163465k
    GGC runs: 638 -> 629

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-09-21 20:52:08.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-09-22 06:32:19.000000000 +0000
@@ -1,3 +1,61 @@
+2004-09-21 Jeff Law  <law@redhat.com>
+
+	* tree-ssa-dom.c (opt_stats): Move so that it lives just after
+	the opt_stats_d structure.
+	(vrp_data): Change from a varray into a hash table.
+	(vrp_hash_elt): New structure for elements in the vrp hash table.
+	(vrp_hash, vrp_eq):New functions for hashing and testing equality
+	in the vrp hash table.
+	(tree_ssa_dominator_optimize): Initialize VRP_DATA.  Reorganize
+	initialization slightly to make it easier to read.  No longer need
+	to grow/clear the varray.  Instead empty and delete the hash table.
+	(dom_opt_finalize_block): Update due to change of VRP_DATA from
+	a varray to a hash table.
+	(simplify_cond_and_loop_avail_expr, record_range): Similarly.
+
+	* tree-ssa-ccp.c (get_default_value): If we have a constant
+	value recorded for an SSA_NAME, then use that constant as
+	the initial lattice value.
+	(substitute_and_fold): Transfer equivalences discovered into
+	SSA_NAME_EQUIV.
+ 
+	* tree.h (SSA_NAME_EQUIV): Add comments.
+	(SET_SSA_NAME_EQUIV): Similarly.
+
+2004-09-21  David Edelsohn  <edelsohn@gnu.org>
+
+	* config/rs6000/linux64.h (PROCESSOR_DEFAULT64): Default to POWER4.
+
+	* config/rs6000/rs6000.c (rs6000_adjust_cost): dep_insn is used.
+
+2004-09-21  Mark Mitchell  <mark@codesourcery.com>
+
+	* c-decl.c (implicityl_declare): Call maybe_apply_renaming_pragma.
+	(finish_decl): Likewise.
+
+2004-09-21  Devang Patel  <dpatel@apple.com>
+
+	* tree.def (VEC_COND_EXPR): New tree node.
+	* tree-ssa-operands.c (get_expr_operands): Handle VEC_COND_EXPR.
+	
+2004-09-21  Stan Shebs  <shebs@apple.com>
+
+	* config/rs6000/darwin-tramp.asm: Add __ppc64__ case.
+	* config/rs6000/darwin-world.asm: Likewise.
+	
+2004-09-21  Daniel Berlin  <dberlin@dberlin.org>
+
+	* tree-ssa.c (verify_def): Use print_generic_stmt,
+	not debug_generic_stmt.
+	(verify_use): Ditto.
+	(verify_phi_args): Ditto.
+	(verify_ssa): Ditto.
+
+2004-09-21  Paul Brook  <paul@codesourcery.com>
+
+	* varasm.c (default_assemble_integer): Return false for values wider
+	than the target word size.  Works around GAS bug.
+
 2004-09-21  Zack Weinberg  <zack@codesourcery.com>
 
 	* reg-notes.def (REG_DEP_TRUE): New entry, place first so it
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2004-09-21 20:52:09.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2004-09-22 06:32:20.000000000 +0000
@@ -1,3 +1,11 @@
+2004-09-21  Ziemowit Laski  <zlaski@apple.com>
+
+	* cp-lang.c (LANG_HOOKS_FOLD_OBJ_TYPE_REF): Moved here from
+	cp-objcp-common.h.
+	(objcp_tsubst_copy_and_build): Reformat function signature.
+	* cp-objcp-common.h (objcp_tsubst_copy_and_build): Likewise.
+	(LANG_HOOKS_FOLD_OBJ_TYPE_REF): Moved to cp-lang.c.
+
 2004-09-21  Zack Weinberg  <zack@codesourcery.com>
 
 	* parser.c (cp_lexer_peek_token, cp_lexer_consume_token):

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]