GCC memory consumption decreased by recent patch

gcctest@suse.de gcctest@suse.de
Tue Mar 8 02:35:00 GMT 2005


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: 24661k
    Peak memory use before GGC: 9359k
    Peak memory use after GGC: 8673k
    Maximum of released memory in single GGC run: 2865k
    Garbage: 41675k
    Leak: 6395k
    Overhead: 5772k
    GGC runs: 327

comparing combine.c compilation at -O1 level:
    Overall memory needed: 24505k -> 24513k
    Peak memory use before GGC: 8673k -> 8674k
    Peak memory use after GGC: 8093k -> 8094k
    Maximum of released memory in single GGC run: 2026k -> 2025k
    Garbage: 58442k -> 58425k
    Leak: 6756k -> 6756k
    Overhead: 9864k -> 9858k
    GGC runs: 501

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29145k -> 29141k
    Peak memory use before GGC: 12671k
    Peak memory use after GGC: 12544k
    Maximum of released memory in single GGC run: 2533k -> 2532k
    Garbage: 78281k -> 78317k
    Leak: 6594k -> 6594k
    Overhead: 14171k -> 14181k
    GGC runs: 521 -> 520

comparing combine.c compilation at -O3 level:
    Overall memory needed: 30849k -> 30781k
    Peak memory use before GGC: 12713k -> 12707k
    Peak memory use after GGC: 12544k
    Maximum of released memory in single GGC run: 3392k -> 3384k
    Garbage: 105939k -> 105965k
    Leak: 7189k -> 7189k
    Overhead: 19036k -> 19040k
    GGC runs: 583 -> 582

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114212k
    Peak memory use before GGC: 74821k
    Peak memory use after GGC: 45494k
    Maximum of released memory in single GGC run: 39413k
    Garbage: 152830k
    Leak: 10984k
    Overhead: 19970k
    GGC runs: 273

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 124632k -> 124308k
    Peak memory use before GGC: 78641k
    Peak memory use after GGC: 70036k
    Maximum of released memory in single GGC run: 40781k -> 40773k
    Garbage: 369233k -> 369239k
    Leak: 11361k -> 11360k
    Overhead: 71887k -> 71916k
    GGC runs: 398 -> 400

comparing insn-attrtab.c compilation at -O2 level:
  Ovarall memory allocated via mmap and sbrk decreased from 148936k to 137764k, overall -8.11%
    Overall memory needed: 148936k -> 137764k
    Peak memory use before GGC: 97678k -> 97674k
    Peak memory use after GGC: 83497k -> 83493k
    Maximum of released memory in single GGC run: 39163k
    Garbage: 486979k -> 487109k
    Leak: 11252k -> 11244k
    Overhead: 87109k -> 87133k
    GGC runs: 342 -> 343

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 147500k -> 148928k
    Peak memory use before GGC: 97679k -> 97680k
    Peak memory use after GGC: 83499k
    Maximum of released memory in single GGC run: 39162k
    Garbage: 487787k -> 487899k
    Leak: 11287k -> 11287k
    Overhead: 87239k -> 87262k
    GGC runs: 348 -> 349

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 111952k
    Peak memory use before GGC: 87325k
    Peak memory use after GGC: 85900k
    Maximum of released memory in single GGC run: 19511k
    Garbage: 246370k
    Leak: 55513k
    Overhead: 43275k
    GGC runs: 366

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 104033k
    Peak memory use before GGC: 86183k
    Peak memory use after GGC: 85119k
    Maximum of released memory in single GGC run: 18950k
    Garbage: 435088k -> 435089k
    Leak: 56863k -> 56863k
    Overhead: 65172k -> 65187k
    GGC runs: 513

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 104249k
    Peak memory use before GGC: 86184k
    Peak memory use after GGC: 85119k
    Maximum of released memory in single GGC run: 18951k
    Garbage: 476419k -> 476540k
    Leak: 57427k
    Overhead: 74921k -> 74952k
    GGC runs: 570 -> 569

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 105353k -> 105349k
    Peak memory use before GGC: 87323k
    Peak memory use after GGC: 86199k
    Maximum of released memory in single GGC run: 19400k
    Garbage: 481575k -> 481661k
    Leak: 57631k -> 57631k
    Overhead: 75619k -> 75643k
    GGC runs: 557

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-03-07 21:06:05.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-03-08 01:37:05.000000000 +0000
@@ -1,3 +1,68 @@
+2005-03-07  Per Bothner  <per@bothner.com>
+
+	* tree.h (DECL_IS_BUILTIN): Reverted my patch from earlier today.
+
+2005-03-06  Andrew Pinski  <pinskia@physics.uc.edu>
+	
+	PR tree-opt/17671
+	* tree-ssa-phiopt.c (tree_ssa_phiopt): Rewrite so we base the
+	bbs on the COND_EXPR instead of the PHI_NODEs.
+	(candidate_bb_for_phi_optimization): Remove.
+	(replace_phi_with_stmt): Rename to ...
+	(replace_phi_edge_with_variable): this and change so that we
+	replace the phi argument instead of removing the PHI.
+	(conditional_replacement): Change so we deal with PHI with more
+	than two arguments.
+	(value_replacement): Likewise.
+	(abs_replacement): Likewise.
+
+2005-03-07  Aldy Hernandez  <aldyh@redhat.com>
+
+	* config/rs6000/rs6000-protos.h: Rename output_e500_flip_eq_bit to
+	output_e500_flip_gt_bit.
+
+	* config/rs6000/rs6000.c (print_operand): case D: Print out bit 31
+	as bit 31.
+	(rs6000_generate_compare): Fix logic to look at the correct bits.
+	(output_e500_flip_eq_bit): Rename to output_e500_flip_gt_bit.
+	Look at GT bit.
+	(rs6000_emit_sCOND): Rename gen_e500_flip_eq_bit to
+	gen_e500_flip_gt_bit.  Rename gen_move_from_CR_eq_bit to
+	gen_move_from_CR_gt_bit.
+
+	* config/rs6000/rs6000.md ("move_from_CR_eq_bit"): Change bit
+	("move_from_CR_eq_bit"): Rename to move_from_CR_gt_bit.
+	(UNSPEC_MV_CR_EQ): Rename to UNSPEC_MV_CR_GT.
+
+	* config/rs6000/spe.md ("e500_cr_ior_compare"): New.
+	(E500_CR_IOR_COMPARE): New constant.
+
+2005-03-08  Earl Chew <earl_chew@agilent.com>
+	    David Billinghurst <David.Billinghurst@riotinto.com>
+
+	* config/i386/host-cygwin.c: New file to support precompiled
+	headers on cygwin
+	* config/i386/x-cygwin: Use host-cygwin.c on cygwin host
+	* config.host: Use above files for cygwin host.
+
+2005-03-07  David Edelsohn  <edelsohn@gnu.org>
+
+	* fold-const.c (fold_binary_op_with_conditional_arg): Fix typo
+	ordering ops from earlier change.
+
+2005-03-07  Per Bothner  <per@bothner.com>
+
+	Various fixes to allow us to again build if --enable-mapped-location:
+	* c-decl.c (finish_function): Use SET_EXPR_LOCATION instead of
+	unavailable annotate_with_file_line, if USE_MAPPED_LOCATION.
+	* tree-cfg.c (remove_bb): If USE_MAPPED_LOCATION, change type of
+	local variable loc. Change logic appropriately.
+	* tree-vect-transform.c (vect_finish_stmt_generation): Use
+	EXPR_LOCATION rather than EXPR_LOCUS if USE_MAPPED_LOCATION.	
+	* c-parser.c (c_parser_for_statement): Initialize loc variable.
+	* tree.h (DECL_IS_BUILTIN): Temporarily revert definition of
+	DECL_IS_BUILTIN in the USE_MAPPED_LOCATION because of jc1 issues.
+
 2005-03-07  Richard Sandiford  <rsandifo@redhat.com>
 
 	PR rtl-optimization/19683
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2005-03-05 16:28:49.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2005-03-08 01:37:07.000000000 +0000
@@ -1,3 +1,8 @@
+2005-03-07  Mark Mitchell  <mark@codesourcery.com>
+
+	* class.c (finish_struct_1): Do not warn about non-virtual
+	destructors in Java classes.
+
 2005-03-05  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
 
 	PR c++/19311

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.



More information about the Gcc-regression mailing list