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: 24585k
    Peak memory use before GGC: 9310k
    Peak memory use after GGC: 8624k
    Maximum of released memory in single GGC run: 2912k
    Garbage: 42442k -> 42437k
    Leak: 6118k -> 6118k
    Overhead: 5748k -> 5748k
    GGC runs: 353

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25505k -> 25501k
    Peak memory use before GGC: 9198k
    Peak memory use after GGC: 8720k
    Maximum of released memory in single GGC run: 2060k
    Garbage: 68022k -> 68015k
    Leak: 6514k -> 6514k
    Overhead: 10698k -> 10697k
    GGC runs: 545 -> 546

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29089k -> 29085k
    Peak memory use before GGC: 12705k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 2574k
    Garbage: 82229k -> 82230k
    Leak: 6331k -> 6331k
    Overhead: 14853k -> 14853k
    GGC runs: 547 -> 548

comparing combine.c compilation at -O3 level:
    Overall memory needed: 31593k -> 31485k
    Peak memory use before GGC: 12987k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 3407k
    Garbage: 111160k -> 111193k
    Leak: 6862k -> 6862k
    Overhead: 19934k -> 19934k
    GGC runs: 614 -> 615

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 118468k
    Peak memory use before GGC: 79386k -> 79387k
    Peak memory use after GGC: 46137k
    Maximum of released memory in single GGC run: 43335k -> 43336k
    Garbage: 161981k -> 161992k
    Leak: 10634k -> 10634k
    Overhead: 21268k -> 21268k
    GGC runs: 296

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 129436k -> 129456k
    Peak memory use before GGC: 83952k
    Peak memory use after GGC: 70040k
    Maximum of released memory in single GGC run: 41104k
    Garbage: 445758k -> 445757k
    Leak: 10980k -> 10981k
    Overhead: 79321k -> 79321k
    GGC runs: 430

comparing insn-attrtab.c compilation at -O2 level:
  Overall memory allocated via mmap and sbrk increased from 153912k to 154068k, overall 0.10%
    Overall memory needed: 153912k -> 154068k
    Peak memory use before GGC: 99964k
    Peak memory use after GGC: 85453k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 492647k -> 492648k
    Leak: 10901k -> 10901k
    Overhead: 87595k -> 87595k
    GGC runs: 364

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 153920k -> 153924k
    Peak memory use before GGC: 99966k
    Peak memory use after GGC: 85455k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 493912k -> 493911k
    Leak: 10943k -> 10944k
    Overhead: 87759k -> 87759k
    GGC runs: 372

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 113408k
    Peak memory use before GGC: 89921k
    Peak memory use after GGC: 89026k
    Maximum of released memory in single GGC run: 19894k
    Garbage: 248876k -> 248878k
    Leak: 57792k -> 57792k
    Overhead: 45384k -> 45384k
    GGC runs: 362 -> 361

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88922k -> 88923k
    Peak memory use after GGC: 87937k
    Maximum of released memory in single GGC run: 19407k -> 19408k
    Garbage: 552550k -> 552582k
    Leak: 59815k -> 59824k
    Overhead: 115274k -> 115280k
    GGC runs: 611 -> 610

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88923k
    Peak memory use after GGC: 87937k -> 87938k
    Maximum of released memory in single GGC run: 19408k
    Garbage: 601759k -> 601773k
    Leak: 60405k -> 60405k
    Overhead: 137303k -> 137310k
    GGC runs: 652 -> 651

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 98508k -> 98572k
    Peak memory use before GGC: 90319k
    Peak memory use after GGC: 88770k
    Maximum of released memory in single GGC run: 20097k -> 20096k
    Garbage: 641698k -> 641712k
    Leak: 60760k -> 60736k
    Overhead: 148690k -> 148688k
    GGC runs: 647 -> 645

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-12-20 07:04:39.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-12-20 11:42:11.000000000 +0000
@@ -1,3 +1,34 @@
+2004-12-20  Steven Bosscher  <stevenb@suse.de>
+	    Andrew Pinski  <pinskia@physics.uc.edu>
+
+	PR middle-end/18191
+	PR middle-end/18965
+	PR middle-end/18999
+	* expr.c (categorize_ctor_elements_1): Count the total number
+	of elements in the constructor.
+	(categorize_ctor_elements): Return it in a new argument.
+	* tree.h (categorize_ctor_elements): Adjust prototype.
+	* gimplify.c (gimplify_init_ctor_eval_range): New.
+	(gimplify_init_ctor_eval): Gimplify RANGE_EXPR.
+	(gimplify_init_constructor): Block clear the object if the
+	constructor has fewer elements than the object type.  Only try
+	to add assignments to individual elements when we have to.
+
+2004-12-20  Richard Henderson  <rth@redhat.com>
+
+	* config/i386/i386.c (ix86_init_mmx_sse_builtins): Use 
+	long_long_integer_type_node in building V2DI_type_node.
+
+	* config/i386/emmintrin.h: Use __vector_size__ instead of vector_size.
+	* config/i386/mmintrin.h, config/i386/xmmintrin.h: Likewise.
+
+2004-12-20  Ben Elliston  <bje@au.ibm.com>
+
+	* doc/md.texi (Expander Definitions): Use @emph instead of @strong
+	around Note: text to workaround a limitation of the Info format.
+	* doc/cpp.texi (Invocation): Likewise.
+	* doc/cppopts.texi: Likewise.
+
 2004-12-19  Dale Johannesen  <dalej@apple.com>
 
 	* tree-ssa-loop-ivopts.c (contains_abnormal_ssa_name_p):  Don't

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]