This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
A recent patch increased GCC's memory consumption!
- From: gcctest at suse dot de
- To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
- Date: Thu, 27 Jul 2006 04:01:54 +0000
- Subject: A recent patch increased GCC's memory consumption!
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:
Overall memory needed: 24721k
Peak memory use before GGC: 9160k
Peak memory use after GGC: 8547k
Maximum of released memory in single GGC run: 2580k
Garbage: 38214k
Leak: 6052k
Overhead: 5326k
GGC runs: 307
comparing combine.c compilation at -O1 level:
Overall memory needed: 36369k -> 36353k
Peak memory use before GGC: 16999k
Peak memory use after GGC: 16828k
Maximum of released memory in single GGC run: 2261k
Garbage: 56528k
Leak: 6066k
Overhead: 6069k -> 6069k
GGC runs: 378
comparing combine.c compilation at -O2 level:
Overall memory needed: 26496k
Peak memory use before GGC: 16997k
Peak memory use after GGC: 16828k
Maximum of released memory in single GGC run: 2254k
Garbage: 80296k
Leak: 6170k
Overhead: 8598k -> 8599k
GGC runs: 446
comparing combine.c compilation at -O3 level:
Overall memory needed: 25600k
Peak memory use before GGC: 18087k
Peak memory use after GGC: 17424k
Maximum of released memory in single GGC run: 3329k
Garbage: 109814k
Leak: 6247k
Overhead: 11868k -> 11868k
GGC runs: 493
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 81376k
Peak memory use before GGC: 68248k
Peak memory use after GGC: 43996k
Maximum of released memory in single GGC run: 35708k
Garbage: 138286k
Leak: 9116k
Overhead: 18992k
GGC runs: 241
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 102616k -> 103680k
Peak memory use before GGC: 83566k
Peak memory use after GGC: 77686k
Maximum of released memory in single GGC run: 31934k
Garbage: 268544k
Leak: 8940k
Overhead: 29968k -> 29968k
GGC runs: 235
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 103652k
Peak memory use before GGC: 87827k
Peak memory use after GGC: 79920k
Maximum of released memory in single GGC run: 30382k
Garbage: 314655k
Leak: 8935k
Overhead: 36950k -> 36951k
GGC runs: 263
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 103660k -> 103664k
Peak memory use before GGC: 87853k
Peak memory use after GGC: 79946k
Maximum of released memory in single GGC run: 30573k
Garbage: 315246k
Leak: 8938k
Overhead: 37130k -> 37130k
GGC runs: 267
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 116456k -> 116488k
Peak memory use before GGC: 92791k
Peak memory use after GGC: 91863k
Maximum of released memory in single GGC run: 19688k
Garbage: 214070k
Leak: 47149k
Overhead: 22154k -> 22165k
GGC runs: 416
comparing Gerald's testcase PR8361 compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 95009k to 95347k, overall 0.36%
Peak amount of GGC memory still allocated after garbage collectin increased from 93237k to 93607k, overall 0.40%
Overall memory needed: 113632k -> 113996k
Peak memory use before GGC: 95009k -> 95347k
Peak memory use after GGC: 93237k -> 93607k
Maximum of released memory in single GGC run: 18467k -> 18450k
Garbage: 435581k -> 435582k
Leak: 48579k
Overhead: 31505k -> 31516k
GGC runs: 560
comparing Gerald's testcase PR8361 compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting increased from 95010k to 95348k, overall 0.36%
Peak amount of GGC memory still allocated after garbage collectin increased from 93238k to 93608k, overall 0.40%
Overall memory needed: 113592k -> 113948k
Peak memory use before GGC: 95010k -> 95348k
Peak memory use after GGC: 93238k -> 93608k
Maximum of released memory in single GGC run: 18467k -> 18451k
Garbage: 520513k -> 520532k
Leak: 49267k -> 49266k
Overhead: 39218k -> 39231k
GGC runs: 632 -> 634
comparing Gerald's testcase PR8361 compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 96316k to 96657k, overall 0.35%
Peak amount of GGC memory still allocated after garbage collectin increased from 94523k to 94896k, overall 0.39%
Overall memory needed: 114924k -> 115284k
Peak memory use before GGC: 96316k -> 96657k
Peak memory use after GGC: 94523k -> 94896k
Maximum of released memory in single GGC run: 18768k -> 18758k
Garbage: 537594k -> 537559k
Leak: 49590k -> 49590k
Overhead: 40295k -> 40305k
GGC runs: 650
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2006-07-26 05:34:48.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2006-07-27 02:48:20.000000000 +0000
@@ -1,3 +1,41 @@
+2006-07-27 Jan Hubicka <jh@suse.cz>
+
+ PR rtl-optimization/28071
+ * regmove.c (reg_is_remote_constant_p): Avoid quadratic behaviour.
+ (reg_set_in_bb, max_reg_computed): New static variables.
+ (regmove_optimize): Free the new array.
+ (fixup_match_1): Update call of reg_is_remote_constant_p.
+
+2006-07-26 Jan Hubicka <jh@suse.cz>
+
+ PR tree-optimization/27882
+ * cgraph.c (cgraph_remove_node): Clear needed, reachable, next, previous
+ and decl fields.
+ * cgraphunit.c (cgraph_reset_node): Expect cgraph_remove_node to kill
+ next pointer
+ (cgraph_analyze_compilation_unit): Likewise.
+ * ipa.c (cgraph_remove_unreachable_nodes): Likewise.
+ * ipa-inline.c (cgraph_decide_recursive_inlining): Likewise.
+ (cgraph_early_inlinine): Make order garbage collected.
+ * Makefile.in (gt-ipa-inline): New garbagecollected file.
+
+2006-07-26 Daniel Jacobowitz <dan@codesourcery.com>
+
+ * dbxout.c (output_types_sort): Add a comment.
+ (output_used_types): Free the VEC.
+
+2006-07-26 Daniel Jacobowitz <dan@codesourcery.com>
+
+ * function.c (reorder_fix_fragments): Delete.
+ (reorder_blocks): Don't call it.
+ (reorder_blocks_1): Put all subblocks under the origin block.
+
+2006-07-26 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR rtl-optimization/27907
+ * expr.c (force_operand): Use convert_move to handle FLOAT_EXTEND and
+ FLOAT_TRUNCATE.
+
2006-07-25 Roger Sayle <roger@eyesopen.com>
PR middle-end/28473
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.