A recent patch increased GCC's memory consumption in some cases!

gcctest@suse.de gcctest@suse.de
Mon May 8 23:58:00 GMT 2006


Hi,

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

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


comparing combine.c compilation at -O0 level:
  Peak amount of GGC memory still allocated after garbage collecting decreased from 8897k to 8627k, overall -3.13%
  Amount of produced GGC garbage increased from 38655k to 40440k, overall 4.62%
  Amount of memory still referenced at the end of compilation decreased from 6733k to 6444k, overall -4.47%
    Overall memory needed: 25088k -> 24868k
    Peak memory use before GGC: 9509k -> 9240k
    Peak memory use after GGC: 8897k -> 8627k
    Maximum of released memory in single GGC run: 2602k
    Garbage: 38655k -> 40440k
    Leak: 6733k -> 6444k
    Overhead: 5889k -> 6151k
    GGC runs: 304 -> 341

comparing combine.c compilation at -O1 level:
    Overall memory needed: 26892k
    Peak memory use before GGC: 17430k
    Peak memory use after GGC: 17251k
    Maximum of released memory in single GGC run: 2285k
    Garbage: 58927k
    Leak: 6869k
    Overhead: 7055k
    GGC runs: 376

comparing combine.c compilation at -O2 level:
    Overall memory needed: 26892k
    Peak memory use before GGC: 17434k
    Peak memory use after GGC: 17251k
    Maximum of released memory in single GGC run: 2385k
    Garbage: 82952k
    Leak: 6997k
    Overhead: 9702k
    GGC runs: 443

comparing combine.c compilation at -O3 level:
    Overall memory needed: 25992k
    Peak memory use before GGC: 18584k
    Peak memory use after GGC: 17898k
    Maximum of released memory in single GGC run: 3520k
    Garbage: 113661k
    Leak: 7088k
    Overhead: 13233k
    GGC runs: 494

comparing insn-attrtab.c compilation at -O0 level:
  Amount of memory still referenced at the end of compilation increased from 9901k to 10117k, overall 2.18%
    Overall memory needed: 82164k -> 82152k
    Peak memory use before GGC: 69036k -> 69028k
    Peak memory use after GGC: 44790k -> 44783k
    Maximum of released memory in single GGC run: 36009k -> 36008k
    Garbage: 140381k -> 140149k
    Leak: 9901k -> 10117k
    Overhead: 20394k -> 20398k
    GGC runs: 239

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 105932k
    Peak memory use before GGC: 85570k
    Peak memory use after GGC: 79522k
    Maximum of released memory in single GGC run: 32269k
    Garbage: 282719k
    Leak: 10061k
    Overhead: 33387k
    GGC runs: 239

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 109992k
    Peak memory use before GGC: 89997k
    Peak memory use after GGC: 81924k
    Maximum of released memory in single GGC run: 30719k
    Garbage: 330178k
    Leak: 10048k
    Overhead: 40620k
    GGC runs: 265

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 110088k
    Peak memory use before GGC: 90026k
    Peak memory use after GGC: 81952k
    Maximum of released memory in single GGC run: 30923k
    Garbage: 330834k
    Leak: 10052k
    Overhead: 40818k
    GGC runs: 269

comparing Gerald's testcase PR8361 compilation at -O0 level:
  Amount of produced GGC garbage increased from 218001k to 218377k, overall 0.17%
    Overall memory needed: 118248k -> 118236k
    Peak memory use before GGC: 95020k -> 95000k
    Peak memory use after GGC: 94073k -> 94059k
    Maximum of released memory in single GGC run: 20358k -> 20205k
    Garbage: 218001k -> 218377k
    Leak: 49503k -> 49519k
    Overhead: 37967k -> 38035k
    GGC runs: 362

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 115836k
    Peak memory use before GGC: 97667k
    Peak memory use after GGC: 96688k
    Maximum of released memory in single GGC run: 18987k
    Garbage: 463633k
    Leak: 52780k
    Overhead: 51537k
    GGC runs: 505

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 115856k
    Peak memory use before GGC: 97667k
    Peak memory use after GGC: 96687k
    Maximum of released memory in single GGC run: 18987k
    Garbage: 552139k
    Leak: 53676k
    Overhead: 60161k
    GGC runs: 589

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 117136k
    Peak memory use before GGC: 98962k
    Peak memory use after GGC: 97982k
    Maximum of released memory in single GGC run: 19239k
    Garbage: 573995k
    Leak: 54035k
    Overhead: 61258k
    GGC runs: 595

Head of the ChangeLog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2006-05-08 09:34:16.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2006-05-08 22:17:16.000000000 +0000
@@ -1,3 +1,20 @@
+2006-05-08  Eric Christopher  <echristo@apple.com>
+
+	* unwind-dw2-fde-darwin.c (examine_objects): Only check data
+	section for ppc.
+
+2006-05-08  Jan Hubicka  <jh@suse.cz>
+
+	PR middle-end/25962
+	* cgraphunit.c (decide_is_function_needed): When not optimizing even
+	unused static functions are needed.
+
+2006-05-08  Roger Sayle  <roger@eyesopen.com>
+
+	PR target/27158
+	* reload.c (find_reloads_toplev): Only return the simplified SUBREG
+	of a reg_equiv_constant if the result is a legitimate constant.
+
 2006-05-08  Uros Bizjak  <uros@kss-loka.si>
 
 	PR target/27277
@@ -47,7 +64,7 @@
 2006-05-07  Mircea Namolaru  <namolaru@il.ibm.com>
 
         * opts.c (flag_see): remove its setting at -O3.
-	
+
 2006-05-07  Richard Earnshaw  <rearnsha@arm.com>
 
 	* genpeep.c (main): Make insn-peep.c depend on flags.h.
@@ -198,9 +215,9 @@
 2006-05-02  Andrew MacLeod  <amacleod@redhat.com>
 
 	PR tree-optimization/27381
-	* tree-phinodes.c (remove_phi_arg_num): When moving a phi argument, 
+	* tree-phinodes.c (remove_phi_arg_num): When moving a phi argument,
 	maintain the same immediate_use links.
-	* tree-ssa-operands.c (dump_immediate_uses_for): Show iteration marker 
+	* tree-ssa-operands.c (dump_immediate_uses_for): Show iteration marker
 	node rather than segfaulting.
 
 2006-05-03  Jakub Jelinek  <jakub@redhat.com>
@@ -272,7 +289,7 @@
 2006-05-02  David Billinghurst <David.Billinghurst@riotinto.com>
 
 	PR ada/27366
-	* ada/env.c (__gnat_clearenv): Use unsetenv() to clear environment 
+	* ada/env.c (__gnat_clearenv): Use unsetenv() to clear environment
 	on Cygwin.
 
 2006-05-02  Jakub Jelinek  <jakub@redhat.com>


The results can be reproduced by building a 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.

Your testing script.



More information about the Gcc-regression mailing list