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]
A recent patch increased GCC's memory consumption in some cases!

From: gcctest at suse dot de
To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
Date: Wed, 03 Aug 2005 07:29:38 +0000
Subject: A recent patch increased GCC's memory consumption in some cases!
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:
  Amount of memory still referenced at the end of compilation increased from 6690k to 6698k, overall 0.12%
    Overall memory needed: 24865k -> 24781k
    Peak memory use before GGC: 9590k
    Peak memory use after GGC: 8937k
    Maximum of released memory in single GGC run: 2754k -> 2739k
    Garbage: 41361k -> 40379k
    Leak: 6690k -> 6698k
    Overhead: 5813k -> 5813k
    GGC runs: 320 -> 317

comparing combine.c compilation at -O1 level:
  Amount of produced GGC garbage decreased from 66082k to 60453k, overall -9.31%
    Overall memory needed: 26812k
    Peak memory use before GGC: 17362k -> 17359k
    Peak memory use after GGC: 17173k
    Maximum of released memory in single GGC run: 2418k -> 2374k
    Garbage: 66082k -> 60453k
    Leak: 7196k -> 7194k
    Overhead: 7611k -> 7608k
    GGC runs: 413 -> 389

comparing combine.c compilation at -O2 level:
  Amount of produced GGC garbage decreased from 81095k to 75243k, overall -7.78%
    Overall memory needed: 26812k
    Peak memory use before GGC: 17365k -> 17361k
    Peak memory use after GGC: 17173k
    Maximum of released memory in single GGC run: 2503k -> 2459k
    Garbage: 81095k -> 75243k
    Leak: 7438k
    Overhead: 9907k -> 9907k
    GGC runs: 477 -> 457

comparing combine.c compilation at -O3 level:
  Amount of produced GGC garbage decreased from 114978k to 106456k, overall -8.00%
    Overall memory needed: 26812k
    Peak memory use before GGC: 18455k -> 18408k
    Peak memory use after GGC: 18100k -> 18101k
    Maximum of released memory in single GGC run: 3539k -> 3507k
    Garbage: 114978k -> 106456k
    Leak: 7547k
    Overhead: 13538k -> 13530k
    GGC runs: 546 -> 520

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 81648k -> 81076k
    Peak memory use before GGC: 70263k -> 69691k
    Peak memory use after GGC: 45002k
    Maximum of released memory in single GGC run: 37047k -> 36475k
    Garbage: 148647k -> 147322k
    Leak: 10091k -> 9851k
    Overhead: 19857k -> 19857k
    GGC runs: 250 -> 251

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 112560k -> 112120k
    Peak memory use before GGC: 94389k -> 94165k
    Peak memory use after GGC: 83710k -> 83712k
    Maximum of released memory in single GGC run: 32765k -> 32586k
    Garbage: 294362k -> 290394k
    Leak: 10081k -> 10083k
    Overhead: 36715k -> 36719k
    GGC runs: 250 -> 245

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 120156k -> 120252k
    Peak memory use before GGC: 94518k -> 94294k
    Peak memory use after GGC: 83886k -> 83888k
    Maximum of released memory in single GGC run: 32714k -> 32536k
    Garbage: 339827k -> 335814k
    Leak: 10092k
    Overhead: 44968k -> 44965k
    GGC runs: 278 -> 273

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 120256k -> 120440k
    Peak memory use before GGC: 94539k -> 94317k
    Peak memory use after GGC: 83907k -> 83911k
    Maximum of released memory in single GGC run: 33029k -> 32849k
    Garbage: 340373k -> 336351k
    Leak: 10108k
    Overhead: 45114k -> 45112k
    GGC runs: 281 -> 275

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 118616k
    Peak memory use before GGC: 95321k -> 95329k
    Peak memory use after GGC: 94374k
    Maximum of released memory in single GGC run: 20159k -> 20170k
    Garbage: 227542k -> 226620k
    Leak: 49361k -> 49361k
    Overhead: 36908k -> 36902k
    GGC runs: 344 -> 342

comparing Gerald's testcase PR8361 compilation at -O1 level:
  Peak amount of GGC memory allocated before garbage collecting increased from 94274k to 94383k, overall 0.12%
  Peak amount of GGC memory still allocated after garbage collectin increased from 93338k to 93446k, overall 0.12%
  Amount of produced GGC garbage decreased from 606301k to 574655k, overall -5.51%
    Overall memory needed: 105532k -> 105708k
    Peak memory use before GGC: 94274k -> 94383k
    Peak memory use after GGC: 93338k -> 93446k
    Maximum of released memory in single GGC run: 19336k -> 19454k
    Garbage: 606301k -> 574655k
    Leak: 55622k -> 55622k
    Overhead: 68318k -> 68303k
    GGC runs: 516 -> 494

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Peak amount of GGC memory allocated before garbage collecting increased from 94274k to 94383k, overall 0.12%
  Peak amount of GGC memory still allocated after garbage collectin increased from 93339k to 93446k, overall 0.11%
  Amount of produced GGC garbage decreased from 682313k to 649084k, overall -5.12%
    Overall memory needed: 105592k -> 105724k
    Peak memory use before GGC: 94274k -> 94383k
    Peak memory use after GGC: 93339k -> 93446k
    Maximum of released memory in single GGC run: 19336k -> 19454k
    Garbage: 682313k -> 649084k
    Leak: 56733k -> 56732k
    Overhead: 79029k -> 78969k
    GGC runs: 571 -> 548

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Amount of produced GGC garbage decreased from 740976k to 703110k, overall -5.39%
    Overall memory needed: 109420k -> 109512k
    Peak memory use before GGC: 95464k
    Peak memory use after GGC: 94518k
    Maximum of released memory in single GGC run: 19608k
    Garbage: 740976k -> 703110k
    Leak: 57742k -> 57742k
    Overhead: 83883k -> 83804k
    GGC runs: 582 -> 557

Head of the ChangeLog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-08-02 21:02:14.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-08-03 06:21:30.000000000 +0000
@@ -1,3 +1,18 @@
+2005-08-03  Andrew Pinski  <pinskia@physics.uc.edu>
+
+	* convert.c (convert_to_integer): Use fold_build1 instead of
+	build1 when converting an integer to an integer.
+
+2005-08-02  Richard Henderson  <rth@redhat.com>
+
+	* combine.c (combine_instructions): Don't use reg_equal/equiv
+	results if the mode doesn't match.
+
+2005-08-02  Mark Mitchell  <mark@codesourcery.com>
+
+	* config/i386/t-mingw32 (NATIVE_SYSTEM_HEADER_DIR): Set it.
+	* doc/fragments.texi (NATIVE_SYSTEM_HEADER_DIR): Document it.
+
 2005-08-02  Richard Henderson  <rth@redhat.com>
 
 	PR 23196


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.
Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]