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: Fri, 11 Mar 2005 06:05:14 +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:
Overall memory needed: 24661k -> 24665k
Peak memory use before GGC: 9359k
Peak memory use after GGC: 8673k
Maximum of released memory in single GGC run: 2865k
Garbage: 41675k -> 41689k
Leak: 6395k
Overhead: 5772k -> 5772k
GGC runs: 327
comparing combine.c compilation at -O1 level:
Overall memory needed: 24517k -> 24461k
Peak memory use before GGC: 8674k -> 8667k
Peak memory use after GGC: 8094k -> 8093k
Maximum of released memory in single GGC run: 2025k -> 2022k
Garbage: 58425k -> 58319k
Leak: 6756k -> 6754k
Overhead: 9858k -> 9835k
GGC runs: 501
comparing combine.c compilation at -O2 level:
Overall memory needed: 29145k -> 29157k
Peak memory use before GGC: 12671k -> 12670k
Peak memory use after GGC: 12544k
Maximum of released memory in single GGC run: 2596k
Garbage: 78822k -> 78898k
Leak: 6592k -> 6590k
Overhead: 14261k -> 14264k
GGC runs: 522 -> 523
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 106566k to 106705k, overall 0.13%
Overall memory needed: 30813k -> 30809k
Peak memory use before GGC: 12718k -> 12716k
Peak memory use after GGC: 12544k
Maximum of released memory in single GGC run: 3420k -> 3423k
Garbage: 106566k -> 106705k
Leak: 7198k -> 7195k
Overhead: 19123k -> 19107k
GGC runs: 582
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 114212k
Peak memory use before GGC: 74821k
Peak memory use after GGC: 45494k
Maximum of released memory in single GGC run: 39413k
Garbage: 152830k -> 152827k
Leak: 10984k
Overhead: 19970k -> 19970k
GGC runs: 273
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 124308k -> 124708k
Peak memory use before GGC: 78641k
Peak memory use after GGC: 70036k
Maximum of released memory in single GGC run: 40773k
Garbage: 369239k -> 369241k
Leak: 11360k
Overhead: 71916k
GGC runs: 400
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 147456k
Peak memory use before GGC: 97678k
Peak memory use after GGC: 83497k
Maximum of released memory in single GGC run: 39453k
Garbage: 489756k -> 489759k
Leak: 11249k
Overhead: 87472k
GGC runs: 343
comparing insn-attrtab.c compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 137828k to 147496k, overall 7.01%
Overall memory needed: 137828k -> 147496k
Peak memory use before GGC: 97680k
Peak memory use after GGC: 83499k
Maximum of released memory in single GGC run: 39453k
Garbage: 490563k -> 490566k
Leak: 11286k
Overhead: 87602k
GGC runs: 349
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 111956k
Peak memory use before GGC: 87328k
Peak memory use after GGC: 85903k
Maximum of released memory in single GGC run: 19511k
Garbage: 246357k -> 246356k
Leak: 55515k
Overhead: 43274k -> 43274k
GGC runs: 365
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory needed: 104057k -> 104037k
Peak memory use before GGC: 86186k
Peak memory use after GGC: 85121k
Maximum of released memory in single GGC run: 18951k
Garbage: 435075k -> 435000k
Leak: 56866k -> 56860k
Overhead: 65185k -> 65155k
GGC runs: 513
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory needed: 104257k
Peak memory use before GGC: 86186k
Peak memory use after GGC: 85121k
Maximum of released memory in single GGC run: 18950k
Garbage: 477994k -> 477988k
Leak: 57434k -> 57428k
Overhead: 75187k -> 75181k
GGC runs: 570 -> 568
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory needed: 105353k
Peak memory use before GGC: 87325k
Peak memory use after GGC: 86201k
Maximum of released memory in single GGC run: 19400k
Garbage: 483219k -> 483147k
Leak: 57618k -> 57622k
Overhead: 75896k -> 75848k
GGC runs: 558 -> 559
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-03-11 00:36:23.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-03-11 05:06:20.000000000 +0000
@@ -1,3 +1,25 @@
+2005-03-11 James A. Morrison <phython@gcc.gnu.org>
+
+ PR tree-optimization/15784
+ * fold-const.c (fold): Fold ~A + 1 to -A. Fold -A - 1
+ and -1 - A to ~A.
+
+ * stmt.c (expand_case): Don't change index_type. Convert minval
+ to the proper type.
+
+ PR tree-optimization/20130
+ * fold-const.c (fold): Fold x * -1 into -x.
+
+2005-03-11 Kaz Kojima <kkojima@gcc.gnu.org>
+
+ PR rtl-optimization/20331
+ * rtlanal.c (modified_between_p): Check its address first for MEM.
+ (modified_in_p): Likewise.
+
+2005-03-11 Joseph S. Myers <joseph@codesourcery.com>
+
+ * config.gcc (hppa*64*-*-hpux11*): Use pa/t-hpux-shlib.
+
2005-03-10 Steven Bosscher <stevenb@suse.de>
* expr.c (expand_expr_real_1): If possible, use a conditional
@@ -707,7 +729,7 @@
Revert for now:
2005-03-03 James A. Morrison <phython@gcc.gnu.org>
PR tree-optimization/15784
- * fold-const.c (fold): Fold ~A + 1 to -1. Fold -A - 1
+ * fold-const.c (fold): Fold ~A + 1 to -A. Fold -A - 1
and -1 - A to ~A.
2005-03-04 Ben Elliston <bje@au.ibm.com>
@@ -741,7 +763,7 @@
2005-03-03 James A. Morrison <phython@gcc.gnu.org>
PR tree-optimization/15784
- * fold-const.c (fold): Fold ~A + 1 to -1. Fold -A - 1
+ * fold-const.c (fold): Fold ~A + 1 to -A. Fold -A - 1
and -1 - A to ~A.
2005-03-03 David Edelsohn <edelsohn@gnu.org>
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.