GCC memory consumption increased by recent patch!
gcctest@suse.de
gcctest@suse.de
Sun Sep 26 21:45:00 GMT 2004
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: 24125k -> 24121k
Peak memory use before GGC: 9296k
Peak memory use after GGC: 8607k
Maximum of released memory in single GGC run: 2870k
Garbage: 42629k
Leak: 6090k
Overhead: 5588k
GGC runs: 363
comparing combine.c compilation at -O1 level:
Amount of produced GGC garbage increased from 69012k to 69180k, overall 0.24%
Overall memory needed: 25585k
Peak memory use before GGC: 9377k
Peak memory use after GGC: 8800k
Maximum of released memory in single GGC run: 2031k
Garbage: 69012k -> 69180k
Leak: 6674k
Overhead: 11060k -> 11094k
GGC runs: 575
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 84129k to 84273k, overall 0.17%
Overall memory needed: 28865k -> 28885k
Peak memory use before GGC: 12772k
Peak memory use after GGC: 12613k
Maximum of released memory in single GGC run: 2525k
Garbage: 84129k -> 84273k
Leak: 6428k
Overhead: 15609k -> 15636k
GGC runs: 571
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 112018k to 112175k, overall 0.14%
Amount of memory still referenced at the end of compilation increased from 6913k to 6929k, overall 0.23%
Overall memory needed: 20544k
Peak memory use before GGC: 13044k
Peak memory use after GGC: 12692k
Maximum of released memory in single GGC run: 3362k
Garbage: 112018k -> 112175k
Leak: 6913k -> 6929k
Overhead: 20652k -> 20684k
GGC runs: 637
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 116476k
Peak memory use before GGC: 77101k
Peak memory use after GGC: 45186k
Maximum of released memory in single GGC run: 42129k
Garbage: 159505k
Leak: 10645k
Overhead: 19805k
GGC runs: 310
comparing insn-attrtab.c compilation at -O1 level:
Amount of produced GGC garbage increased from 452514k to 453085k, overall 0.13%
Overall memory needed: 133128k -> 133084k
Peak memory use before GGC: 93162k
Peak memory use after GGC: 71529k
Maximum of released memory in single GGC run: 41234k
Garbage: 452514k -> 453085k
Leak: 11078k
Overhead: 73596k -> 73707k
GGC runs: 461
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 207744k
Peak memory use before GGC: 108725k
Peak memory use after GGC: 87092k
Maximum of released memory in single GGC run: 34490k
Garbage: 502029k -> 502446k
Leak: 11218k
Overhead: 82991k -> 83073k
GGC runs: 384
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 207736k
Peak memory use before GGC: 108726k
Peak memory use after GGC: 87093k
Maximum of released memory in single GGC run: 34491k
Garbage: 503198k -> 503617k
Leak: 11256k
Overhead: 83387k -> 83469k
GGC runs: 393
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 115352k
Peak memory use before GGC: 92231k
Peak memory use after GGC: 90025k
Maximum of released memory in single GGC run: 20139k
Garbage: 265688k
Leak: 60277k
Overhead: 47198k
GGC runs: 378
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory needed: 109300k -> 109320k
Peak memory use before GGC: 95751k
Peak memory use after GGC: 88883k
Maximum of released memory in single GGC run: 19570k
Garbage: 594162k -> 594441k
Leak: 62349k -> 62357k
Overhead: 130957k -> 131029k
GGC runs: 605
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory needed: 110336k -> 110308k
Peak memory use before GGC: 95751k
Peak memory use after GGC: 88883k
Maximum of released memory in single GGC run: 19569k
Garbage: 646972k -> 647298k
Leak: 62912k
Overhead: 154222k -> 154283k
GGC runs: 637 -> 638
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory needed: 108020k -> 108024k
Peak memory use before GGC: 91613k
Peak memory use after GGC: 90197k
Maximum of released memory in single GGC run: 20253k
Garbage: 682382k -> 682712k
Leak: 63341k -> 63333k
Overhead: 163378k -> 163435k
GGC runs: 626
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2004-09-26 06:56:20.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2004-09-26 18:52:33.000000000 +0000
@@ -1,3 +1,40 @@
+2004-09-26 Roger Sayle <roger@eyesopen.com>
+ Giovanni Bajo <giovannibajo@gcc.gnu.org>
+
+ PR middle-end/17112
+ * stor-layout.c (compute_record_mode): For records with a single
+ field, only use the field's mode if its size matches what we'd
+ have choosen for the record ourselves. This forces the use of
+ BLKmode for packed records that don't completely fill a mode.
+
+2004-09-26 Roger Sayle <roger@eyesopen.com>
+
+ PR middle-end/17151
+ * combine.c (force_to_mode): Remove dubious early return test that
+ inhibits further optimization.
+
+2004-09-26 Kazu Hirata <kazu@cs.umass.edu>
+
+ * profile.c: Fix a comment typo.
+
+2004-09-26 Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
+
+ PR bootstrap/17591
+ * tree-ssa-loop-im.c (for_each_index): Call callback for component_refs
+ with varying offset.
+ * tree-ssa-loop-ivopts.c (abnormal_ssa_name_p): New function.
+ (idx_contains_abnormal_ssa_name_p): Scan step and lower bound for
+ ARRAY_REFS.
+ (expr_invariant_in_loop_p): New function.
+ (idx_find_step): Handle step and lower bound for ARRAY_REFs. Handle
+ component_ref_field_offset for COMPONENT_REFs. Do not allow
+ ALIGN_INDIRECT_REFs and MISALIGNED_INDIRECT_REFs.
+ (add_address_candidates): Do not handle ALIGN_INDIRECT_REFs and
+ MISALIGNED_INDIRECT_REFs.
+ (idx_remove_ssa_names): Handle step and lower bound for ARRAY_REFs.
+ (rewrite_address_base): Do not handle ALIGN_INDIRECT_REFs and
+ MISALIGNED_INDIRECT_REFs.
+
2004-09-26 Joseph S. Myers <jsm@polyomino.org.uk>
PR c/11459
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.
More information about the Gcc-regression
mailing list