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: Mon, 01 May 2006 22:19:23 +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: 25068k
Peak memory use before GGC: 9509k
Peak memory use after GGC: 8897k
Maximum of released memory in single GGC run: 2602k
Garbage: 38655k
Leak: 6733k
Overhead: 5889k
GGC runs: 304
comparing combine.c compilation at -O1 level:
Amount of produced GGC garbage increased from 59221k to 59429k, overall 0.35%
Amount of memory still referenced at the end of compilation increased from 6870k to 6878k, overall 0.12%
Overall memory needed: 26892k
Peak memory use before GGC: 17430k
Peak memory use after GGC: 17251k
Maximum of released memory in single GGC run: 2287k
Garbage: 59221k -> 59429k
Leak: 6870k -> 6878k
Overhead: 7038k -> 7056k
GGC runs: 379
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 83248k to 83469k, overall 0.27%
Overall memory needed: 26892k
Peak memory use before GGC: 17435k
Peak memory use after GGC: 17251k
Maximum of released memory in single GGC run: 2387k
Garbage: 83248k -> 83469k
Leak: 6996k
Overhead: 9695k -> 9712k
GGC runs: 446 -> 445
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 113377k to 113933k, overall 0.49%
Overall memory needed: 25992k
Peak memory use before GGC: 18595k
Peak memory use after GGC: 17898k
Maximum of released memory in single GGC run: 3516k
Garbage: 113377k -> 113933k
Leak: 7086k
Overhead: 13188k -> 13231k
GGC runs: 494 -> 495
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 82164k
Peak memory use before GGC: 69036k
Peak memory use after GGC: 44790k
Maximum of released memory in single GGC run: 36009k
Garbage: 140381k
Leak: 9901k
Overhead: 20394k
GGC runs: 239
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 105676k -> 105936k
Peak memory use before GGC: 85627k -> 85629k
Peak memory use after GGC: 79523k -> 79525k
Maximum of released memory in single GGC run: 32286k
Garbage: 283066k -> 283074k
Leak: 10065k
Overhead: 33382k -> 33382k
GGC runs: 239
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 109720k -> 109980k
Peak memory use before GGC: 90038k
Peak memory use after GGC: 81927k
Maximum of released memory in single GGC run: 30736k
Garbage: 330594k -> 330606k
Leak: 10051k
Overhead: 40625k -> 40626k
GGC runs: 265
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 109848k -> 110108k
Peak memory use before GGC: 90064k
Peak memory use after GGC: 81953k
Maximum of released memory in single GGC run: 30935k -> 30941k
Garbage: 331207k -> 331262k
Leak: 10056k
Overhead: 40822k -> 40825k
GGC runs: 268 -> 269
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 118248k
Peak memory use before GGC: 95020k
Peak memory use after GGC: 94073k
Maximum of released memory in single GGC run: 20358k
Garbage: 218001k
Leak: 49503k
Overhead: 37967k
GGC runs: 362
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 463201k to 466292k, overall 0.67%
Overall memory needed: 115832k
Peak memory use before GGC: 97667k
Peak memory use after GGC: 96688k
Maximum of released memory in single GGC run: 18987k
Garbage: 463201k -> 466292k
Leak: 52789k
Overhead: 51422k -> 51599k
GGC runs: 508 -> 510
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 552092k to 555380k, overall 0.60%
Overall memory needed: 115860k -> 115864k
Peak memory use before GGC: 97667k
Peak memory use after GGC: 96687k
Maximum of released memory in single GGC run: 18987k
Garbage: 552092k -> 555380k
Leak: 53690k
Overhead: 60166k -> 60353k
GGC runs: 587 -> 590
comparing Gerald's testcase PR8361 compilation at -O3 level:
Amount of produced GGC garbage increased from 571901k to 576678k, overall 0.84%
Overall memory needed: 117136k
Peak memory use before GGC: 98962k
Peak memory use after GGC: 97982k
Maximum of released memory in single GGC run: 19239k
Garbage: 571901k -> 576678k
Leak: 54048k -> 54047k
Overhead: 61135k -> 61395k
GGC runs: 596 -> 599
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2006-05-01 10:18:59.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2006-05-01 21:04:47.000000000 +0000
@@ -1,3 +1,80 @@
+2006-05-01 DJ Delorie <dj@redhat.com>
+
+ * vec.c: Include bconfig.h when appropriate.
+ * Makefile.in (build/vec.o): Adjust dependencies.
+ * mkconfig.sh: Make sure config.h isn't used for build machine
+ compiles.
+
+2006-05-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ * tree-into-ssa.c (phis_to_rewrite, blocks_with_phis_to_rewrite): New
+ variables.
+ (mark_phi_for_rewrite): New function.
+ (insert_phi_nodes_for, mark_use_interesting): Call
+ mark_phi_for_rewrite.
+ (rewrite_update_phi_arguments): Traverse only phis in phis_to_rewrite.
+ (update_ssa): Initialize and free phis_to_rewrite.
+
+2006-05-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR rtl-optimization/27291
+ * loop-doloop.c (add_test, doloop_modify): Handle the case condition is
+ folded to a constant.
+
+2006-05-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR tree-optimization/27283
+ * tree-ssa-loop-ivopts.c (struct nfe_cache_elt): Store just trees,
+ not whole # of iteration descriptions.
+ (niter_for_exit): Return just # of iterations. Fail if # of iterations
+ uses abnormal ssa name.
+ (niter_for_single_dom_exit): Ditto.
+ (find_induction_variables, may_eliminate_iv): Expect niter_for_exit to
+ return just the number of iterations.
+
+2006-05-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR tree-optimization/27144
+ * tree-ssa-loop-niter.c (derive_constant_upper_bound): New function.
+ (record_estimate): Only record constant upper bound.
+ (infer_loop_bounds_from_undefined): Call
+ compute_estimated_nb_iterations just once.
+ (proved_non_wrapping_p): Renamed to ...
+ (n_of_executions_at_most): ... this. Expect bound to be a constant.
+ (convert_step_widening, scev_probably_wraps_p): Call
+ n_of_executions_at_most instead of proved_non_wrapping_p.
+ (substitute_in_loop_info): Do not replace values in bounds.
+ * cfgloop.h (struct nb_iter_bound): Remove "additional" field. Update
+ comments.
+
+2006-05-01 Richard Henderson <rth@redhat.com>
+
+ PR c/27358
+ * c-parser.c (c_parser_skip_to_end_of_block_or_statement): Move after
+ c_parser_skip_to_pragma_eol. Convert to switch statement. Handle
+ CPP_PRAGMA.
+
+2006-05-01 Roger Sayle <roger@eyesopen.com>
+
+ * c-typeck.c (parser_build_binary_op): Don't call the function
+ unsigned_conversion_warning to spot operand/result type overflow.
+ (build_binary_op): Instead, call convert_and_check instead of
+ convert to report the problem when the operands are promoted.
+ * c-common.c (unsigned_conversion_warning): Make static.
+ * c-common.h (unsigned_conversion_warning): Delete prototype.
+
+2006-05-01 Richard Guenther <rguenther@suse.de>
+
+ PR tree-optimization/26726
+ * tree-ssa-loop-ivopts.c (idx_find_step): Mark source of the
+ problem ...
+ (find_interesting_uses_address): ... we work around here
+ by folding INDIRECT_REFs in the substituted base.
+
+2006-05-01 Diego Novillo <dnovillo@redhat.com>
+
+ * omp-low.c (dump_omp_region): Add newlines.
+
2006-04-30 Roger Sayle <roger@eyesopen.com>
* common.opt (Woverflow): New command line option.
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.