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

From: gcctest at suse dot de
To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
Date: Sat, 14 May 2005 03:39:18 +0000
Subject: 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
    Peak memory use after GGC: 8746k
    Maximum of released memory in single GGC run: 2798k
    Garbage: 42297k
    Leak: 6479k
    Overhead: 5872k
    GGC runs: 327

comparing combine.c compilation at -O1 level:
    Overall memory needed: 27400k -> 27360k
    Peak memory use before GGC: 8885k -> 8884k
    Peak memory use after GGC: 8543k
    Maximum of released memory in single GGC run: 2236k -> 2230k
    Garbage: 63515k -> 63369k
    Leak: 6839k -> 6839k
    Overhead: 7722k -> 7719k
    GGC runs: 524 -> 522

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: 2625k -> 2624k
    Garbage: 88593k -> 87971k
    Leak: 6655k -> 6654k
    Overhead: 11075k -> 11049k
    GGC runs: 538 -> 537

comparing combine.c compilation at -O3 level:
  Peak amount of GGC memory allocated before garbage collecting run decreased from 15326k to 14396k, overall -6.46%
  Peak amount of GGC memory still allocated after garbage collectin increased from 12920k to 12941k, overall 0.16%
  Amount of memory still referenced at the end of compilation increased from 7119k to 7133k, overall 0.20%
    Overall memory needed: 22748k -> 22508k
    Peak memory use before GGC: 15326k -> 14396k
    Peak memory use after GGC: 12920k -> 12941k
    Maximum of released memory in single GGC run: 3092k -> 3073k
    Garbage: 123345k -> 122530k
    Leak: 7119k -> 7133k
    Overhead: 15282k -> 15261k
    GGC runs: 610 -> 611

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 85872k
    Peak memory use before GGC: 74238k
    Peak memory use after GGC: 45259k
    Maximum of released memory in single GGC run: 38092k
    Garbage: 154411k
    Leak: 11423k
    Overhead: 19887k
    GGC runs: 267

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 103500k -> 103528k
    Peak memory use before GGC: 81336k
    Peak memory use after GGC: 66510k
    Maximum of released memory in single GGC run: 35980k
    Garbage: 308183k -> 308184k
    Leak: 11466k
    Overhead: 37959k -> 37959k
    GGC runs: 386 -> 385

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 140432k -> 140460k
    Peak memory use before GGC: 107836k -> 107782k
    Peak memory use after GGC: 82699k -> 82775k
    Maximum of released memory in single GGC run: 35344k
    Garbage: 404702k -> 404698k
    Leak: 11434k
    Overhead: 50828k -> 50826k
    GGC runs: 336

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 140432k -> 140496k
    Peak memory use before GGC: 107837k -> 107783k
    Peak memory use after GGC: 82702k -> 82778k
    Maximum of released memory in single GGC run: 35343k -> 35344k
    Garbage: 405479k -> 405477k
    Leak: 11454k -> 11457k
    Overhead: 50950k -> 50949k
    GGC runs: 343

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 112060k
    Peak memory use before GGC: 87417k
    Peak memory use after GGC: 86002k
    Maximum of released memory in single GGC run: 20638k
    Garbage: 247948k
    Leak: 53802k
    Overhead: 43074k
    GGC runs: 372

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 94624k
    Peak memory use before GGC: 86531k
    Peak memory use after GGC: 85006k
    Maximum of released memory in single GGC run: 20329k
    Garbage: 601224k -> 601266k
    Leak: 57910k -> 57910k
    Overhead: 76681k -> 76690k
    GGC runs: 622

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 95392k -> 95516k
    Peak memory use before GGC: 86532k
    Peak memory use after GGC: 85006k
    Maximum of released memory in single GGC run: 20329k
    Garbage: 706034k -> 706527k
    Leak: 58791k -> 58791k
    Overhead: 95445k -> 95453k
    GGC runs: 748 -> 747

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 95780k -> 95804k
    Peak memory use before GGC: 87454k
    Peak memory use after GGC: 86288k
    Maximum of released memory in single GGC run: 20589k
    Garbage: 682671k -> 682969k
    Leak: 58921k -> 58921k
    Overhead: 94291k -> 94244k
    GGC runs: 711 -> 710

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-05-13 20:57:34.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-05-14 02:36:14.000000000 +0000
@@ -1,3 +1,28 @@
+2005-05-14  Hans-Peter Nilsson  <hp@axis.com>
+
+	* config/cris/cris.h (Node: Register Classes): Remove obsoleted
+	comment regarding defined register classes.
+	(LEGITIMIZE_RELOAD_ADDRESS): Do not define.
+
+2005-05-14  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* tree-optimize.c (init_tree_optimization_passes): Move
+	pass_merge_phi before the first pass_dominator.
+
+2005-05-13  Richard Earnshaw  <richard.earnshaw@arm.com>
+
+	* arm.h (INITIALIZE_TRAMPOLINE): Make the call to __clear_cache
+	unconditional.
+
+2005-05-13  Josh Conner  <jconner@apple.com>
+
+	* config/arm/arm.c (arm_size_return_regs): New.
+	(thumb_unexpanded_epilogue): replace in-line calculation
+	of return registers with call to arm_size_return_regs.
+	(use_return_insn): Include test of which registers are
+	being used to hold return values, to accommodate
+	vector return values.
+
 2005-05-11  Aldy Hernandez  <aldyh@redhat.com>
 
 	* config/rs6000/sysv4.opt (mlittle): Handle.

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]