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 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: 24633k -> 24637k
    Peak memory use before GGC: 9351k
    Peak memory use after GGC: 8665k
    Maximum of released memory in single GGC run: 2864k
    Garbage: 41665k
    Leak: 6387k
    Overhead: 5772k
    GGC runs: 328

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25461k -> 25469k
    Peak memory use before GGC: 9228k
    Peak memory use after GGC: 8733k
    Maximum of released memory in single GGC run: 2027k
    Garbage: 61218k
    Leak: 6749k
    Overhead: 9980k
    GGC runs: 503

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29501k -> 29521k
    Peak memory use before GGC: 12663k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 2551k -> 2550k
    Garbage: 79124k -> 79173k
    Leak: 6581k -> 6585k
    Overhead: 14082k -> 14094k
    GGC runs: 515

comparing combine.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 20180k to 20212k, overall 0.16%
    Overall memory needed: 20180k -> 20212k
    Peak memory use before GGC: 12793k -> 12794k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 3348k -> 3345k
    Garbage: 106938k -> 106976k
    Leak: 7092k -> 7098k
    Overhead: 18876k -> 18885k
    GGC runs: 581

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114136k
    Peak memory use before GGC: 74739k
    Peak memory use after GGC: 45485k
    Maximum of released memory in single GGC run: 39340k
    Garbage: 152660k
    Leak: 10976k
    Overhead: 19969k
    GGC runs: 273

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 124560k
    Peak memory use before GGC: 78748k
    Peak memory use after GGC: 70095k
    Maximum of released memory in single GGC run: 40765k
    Garbage: 367812k
    Leak: 11353k
    Overhead: 69563k
    GGC runs: 399

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 148992k
    Peak memory use before GGC: 98349k
    Peak memory use after GGC: 83466k
    Maximum of released memory in single GGC run: 39290k
    Garbage: 481104k -> 481106k
    Leak: 11238k -> 11239k
    Overhead: 84672k -> 84673k
    GGC runs: 341

comparing insn-attrtab.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 147352k to 148984k, overall 1.11%
    Overall memory needed: 147352k -> 148984k
    Peak memory use before GGC: 98351k
    Peak memory use after GGC: 83467k
    Maximum of released memory in single GGC run: 39291k
    Garbage: 482146k -> 482150k
    Leak: 11276k -> 11277k
    Overhead: 84822k -> 84822k
    GGC runs: 347

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 111084k
    Peak memory use before GGC: 86879k
    Peak memory use after GGC: 85930k
    Maximum of released memory in single GGC run: 19282k
    Garbage: 245831k
    Leak: 55490k
    Overhead: 43290k
    GGC runs: 366

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 103653k -> 103657k
    Peak memory use before GGC: 85962k
    Peak memory use after GGC: 84927k
    Maximum of released memory in single GGC run: 18946k
    Garbage: 445668k
    Leak: 56770k
    Overhead: 65542k
    GGC runs: 527

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 104689k -> 104713k
    Peak memory use before GGC: 85962k
    Peak memory use after GGC: 84927k
    Maximum of released memory in single GGC run: 18946k
    Garbage: 488445k -> 487718k
    Leak: 57399k -> 57395k
    Overhead: 75213k -> 75156k
    GGC runs: 586 -> 584

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 112397k -> 112409k
    Peak memory use before GGC: 92701k
    Peak memory use after GGC: 86221k
    Maximum of released memory in single GGC run: 19712k
    Garbage: 504269k -> 503792k
    Leak: 57577k -> 57525k
    Overhead: 76897k -> 76868k
    GGC runs: 570 -> 568

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-01-30 05:33:00.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-01-30 20:04:05.000000000 +0000
@@ -1,3 +1,29 @@
+2005-01-30  Richard Henderson  <rth@redhat.com>
+
+	* rtl.c (rtx_equal_p): No early exit for CONST_VECTOR.
+	* varasm.c (const_rtx_hash_1): Handle CONST_VECTOR.
+
+2005-01-30  Richard Henderson  <rth@redhat.com>
+
+	PR target/19700
+	* config/i386/i386.c (ix86_expand_copysign): New.
+	(ix86_split_copysign_const): New.
+	(ix86_split_copysign_var): Rename from ix86_split_copysign, 
+	rearrange op1/nmask operands.
+	* config/i386/i386-protos.h: Update.
+	* config/i386/i386.md (copysignsf3): Use ix86_expand_copysign.
+	(copysigndf3): Likewise.
+	(copysignsf3_const, copysigndf3_const): New.
+	(copysignsf3_var): Rename from copysignsf3, split out splitter
+	and fix split predicate for X constraint.
+	(copysigndf3_var): Similarly.
+
+2005-01-30  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* optabs.c, doc/c-tree.texi, doc/install.texi, doc/md.texi,
+	doc/passes.texi, doc/rtl.texi, doc/sourcebuild.texi,
+	doc/tm.texi, doc/tree-ssa.texi: Update copyright.
+
 2005-01-29  Richard Henderson  <rth@redhat.com>
 
 	PR target/19690

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]