This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
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: Thu, 23 Dec 2004 03:21:59 +0000
- Subject: 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:
Amount of produced GGC garbage increased from 42436k to 42635k, overall 0.47%
Amount of memory still referenced at the end of compilation increased from 6118k to 6198k, overall 1.30%
Overall memory needed: 24569k
Peak memory use before GGC: 9310k
Peak memory use after GGC: 8624k
Maximum of released memory in single GGC run: 2912k
Garbage: 42436k -> 42635k
Leak: 6118k -> 6198k
Overhead: 5748k -> 6027k
GGC runs: 352
comparing combine.c compilation at -O1 level:
Amount of produced GGC garbage increased from 67949k to 68168k, overall 0.32%
Amount of memory still referenced at the end of compilation increased from 6514k to 6594k, overall 1.22%
Overall memory needed: 25533k
Peak memory use before GGC: 9195k
Peak memory use after GGC: 8693k
Maximum of released memory in single GGC run: 2060k
Garbage: 67949k -> 68168k
Leak: 6514k -> 6594k
Overhead: 10667k -> 10966k
GGC runs: 544
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 81918k to 82146k, overall 0.28%
Amount of memory still referenced at the end of compilation increased from 6331k to 6410k, overall 1.24%
Overall memory needed: 29081k
Peak memory use before GGC: 12705k
Peak memory use after GGC: 12578k
Maximum of released memory in single GGC run: 2574k
Garbage: 81918k -> 82146k
Leak: 6331k -> 6410k
Overhead: 14545k -> 14851k
GGC runs: 545
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 110882k to 111174k, overall 0.26%
Amount of memory still referenced at the end of compilation increased from 6878k to 6959k, overall 1.18%
Overall memory needed: 31449k
Peak memory use before GGC: 12987k
Peak memory use after GGC: 12578k
Maximum of released memory in single GGC run: 3407k
Garbage: 110882k -> 111174k
Leak: 6878k -> 6959k
Overhead: 19547k -> 19920k
GGC runs: 613
comparing insn-attrtab.c compilation at -O0 level:
Amount of produced GGC garbage increased from 161992k to 162685k, overall 0.43%
Amount of memory still referenced at the end of compilation increased from 10634k to 10695k, overall 0.57%
Overall memory needed: 118468k
Peak memory use before GGC: 79387k
Peak memory use after GGC: 46137k
Maximum of released memory in single GGC run: 43336k
Garbage: 161992k -> 162685k
Leak: 10634k -> 10695k
Overhead: 21268k -> 22022k
GGC runs: 296
comparing insn-attrtab.c compilation at -O1 level:
Amount of produced GGC garbage increased from 445755k to 446676k, overall 0.21%
Amount of memory still referenced at the end of compilation increased from 10981k to 11042k, overall 0.55%
Overall memory needed: 129456k
Peak memory use before GGC: 83952k
Peak memory use after GGC: 70040k
Maximum of released memory in single GGC run: 41104k
Garbage: 445755k -> 446676k
Leak: 10981k -> 11042k
Overhead: 79320k -> 80301k
GGC runs: 430
comparing insn-attrtab.c compilation at -O2 level:
Amount of produced GGC garbage increased from 492647k to 493569k, overall 0.19%
Amount of memory still referenced at the end of compilation increased from 10901k to 10961k, overall 0.55%
Overall memory needed: 154072k
Peak memory use before GGC: 99964k
Peak memory use after GGC: 85453k
Maximum of released memory in single GGC run: 42091k
Garbage: 492647k -> 493569k
Leak: 10901k -> 10961k
Overhead: 87595k -> 88576k
GGC runs: 364
comparing insn-attrtab.c compilation at -O3 level:
Amount of produced GGC garbage increased from 493911k to 494834k, overall 0.19%
Amount of memory still referenced at the end of compilation increased from 10944k to 11004k, overall 0.55%
Overall memory needed: 153924k
Peak memory use before GGC: 99966k
Peak memory use after GGC: 85455k
Maximum of released memory in single GGC run: 42091k
Garbage: 493911k -> 494834k
Leak: 10944k -> 11004k
Overhead: 87758k -> 88742k
GGC runs: 372
comparing Gerald's testcase PR8361 compilation at -O0 level:
Amount of produced GGC garbage increased from 248876k to 249415k, overall 0.22%
Amount of memory still referenced at the end of compilation increased from 57792k to 58584k, overall 1.37%
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 -> 249415k
Leak: 57792k -> 58584k
Overhead: 45384k -> 46715k
GGC runs: 362
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 483971k to 485830k, overall 0.38%
Amount of memory still referenced at the end of compilation increased from 59823k to 60623k, overall 1.34%
Overall memory needed: 106209k
Peak memory use before GGC: 88922k
Peak memory use after GGC: 87937k
Maximum of released memory in single GGC run: 19407k
Garbage: 483971k -> 485830k
Leak: 59823k -> 60623k
Overhead: 71066k -> 73725k
GGC runs: 552
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 518712k to 520604k, overall 0.36%
Amount of memory still referenced at the end of compilation increased from 60405k to 61205k, overall 1.32%
Overall memory needed: 106269k
Peak memory use before GGC: 88923k
Peak memory use after GGC: 87938k
Maximum of released memory in single GGC run: 19408k
Garbage: 518712k -> 520604k
Leak: 60405k -> 61205k
Overhead: 80693k -> 83386k
GGC runs: 591
comparing Gerald's testcase PR8361 compilation at -O3 level:
Amount of produced GGC garbage increased from 539446k to 541418k, overall 0.37%
Amount of memory still referenced at the end of compilation increased from 60744k to 61549k, overall 1.32%
Overall memory needed: 107909k
Peak memory use before GGC: 90319k
Peak memory use after GGC: 88770k
Maximum of released memory in single GGC run: 20097k
Garbage: 539446k -> 541418k
Leak: 60744k -> 61549k
Overhead: 82416k -> 85193k
GGC runs: 576
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2004-12-22 21:44:25.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2004-12-23 02:20:41.000000000 +0000
@@ -1,3 +1,26 @@
+2004-12-22 Roger Sayle <roger@eyesopen.com>
+
+ * tree-browser.c: Remove obsolete #ifdef HOST_EBCDIC code.
+
+2004-12-23 Alan Modra <amodra@bigpond.net.au>
+
+ PR target/18896
+ * function.c (split_complex_args): Set DECL_ARTIFICIAL, DECL_IGNORED_P
+ for real and imaginary parts if the parm is addressable.
+ (assign_parms_unsplit_complex): If parm addressable, save real
+ and imaginary parts to a stack temp. Pass assign_parm_data_all.
+ (assign_parms): Adjust assign_parms_unsplit_complex call.
+
+2004-12-22 Daniel Berlin <dberlin@dberlin.org>
+
+ * tree.h (DECL_PTA_ALIASVAR): Dead.
+ (struct tree_decl): Remove alias_var field.
+
+2004-12-22 Nathan Sidwell <nathan@codesourcery.com>
+
+ * system.h (IN_RANGE): Restore HOST_WIDE_INT cast.
+ * tree.h (IS_EXPR_CODE_CLASS): Do not use IN_RANGE.
+
2004-12-22 Richard Henderson <rth@redhat.com>
Uros Bizjak <uros@kss-loka.si>
@@ -31,7 +54,7 @@
* gimplify.c (gimplify_decl_expr): Likewise.
(gimplify_type_sizes): Set TYPE_SIZES_GIMPLIFIED. Examine nested
array types.
-
+
2004-12-22 Richard Henderson <rth@redhat.com>
* gimplify.c (eval_save_expr): Remove.
@@ -190,7 +213,7 @@
* c-common.c (set_builtin_user_assembler_name): New.
* c-common.h (set_builtin_user_assembler_name): Declare.
* c-decl.c (finish_decl): Use set_builtin_user_assembler_name
-
+
2004-12-20 Diego Novillo <dnovillo@redhat.com>
PR tree-optimization/19080
@@ -223,7 +246,7 @@
2004-12-20 Richard Henderson <rth@redhat.com>
- * config/i386/i386.c (ix86_init_mmx_sse_builtins): Use
+ * 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.
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2004-12-22 21:44:28.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2004-12-23 02:20:44.000000000 +0000
@@ -1,3 +1,9 @@
+2004-12-23 Giovanni Bajo <giovannibajo@gcc.gnu.org>
+
+ PR c++/18733
+ * pt.c (check_explicit_specialization): Use special logic to validate
+ befriended specializations.
+
2004-12-22 Mark Mitchell <mark@codesourcery.com>
* rtti.c (emit_support_tinfos): Avoid using C99 semantics.
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.