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: Sun, 14 Aug 2005 03:45:08 +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: 24825k
Peak memory use before GGC: 9590k
Peak memory use after GGC: 8937k
Maximum of released memory in single GGC run: 2739k
Garbage: 40379k
Leak: 6698k
Overhead: 5813k
GGC runs: 317
comparing combine.c compilation at -O1 level:
Amount of produced GGC garbage increased from 60498k to 60561k, overall 0.10%
Overall memory needed: 26812k
Peak memory use before GGC: 17359k
Peak memory use after GGC: 17173k
Maximum of released memory in single GGC run: 2373k
Garbage: 60498k -> 60561k
Leak: 7089k -> 7082k
Overhead: 7603k -> 7606k
GGC runs: 389
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 75128k to 75209k, overall 0.11%
Overall memory needed: 26812k
Peak memory use before GGC: 17361k
Peak memory use after GGC: 17173k
Maximum of released memory in single GGC run: 2460k -> 2459k
Garbage: 75128k -> 75209k
Leak: 7440k -> 7432k
Overhead: 9896k -> 9893k
GGC runs: 457 -> 459
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 106286k to 106476k, overall 0.18%
Overall memory needed: 26812k
Peak memory use before GGC: 18403k -> 18416k
Peak memory use after GGC: 18100k -> 18108k
Maximum of released memory in single GGC run: 3496k
Garbage: 106286k -> 106476k
Leak: 7545k -> 7537k
Overhead: 13510k -> 13560k
GGC runs: 519 -> 518
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 81076k
Peak memory use before GGC: 69691k
Peak memory use after GGC: 45002k
Maximum of released memory in single GGC run: 36475k
Garbage: 147322k
Leak: 9851k
Overhead: 19857k
GGC runs: 251
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 112120k -> 112116k
Peak memory use before GGC: 94165k -> 94162k
Peak memory use after GGC: 83712k -> 83709k
Maximum of released memory in single GGC run: 32586k -> 32587k
Garbage: 290384k -> 290390k
Leak: 10083k -> 10077k
Overhead: 36718k -> 36716k
GGC runs: 245
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 120252k -> 120324k
Peak memory use before GGC: 94292k -> 94288k
Peak memory use after GGC: 83886k -> 83882k
Maximum of released memory in single GGC run: 32536k -> 32535k
Garbage: 335802k -> 335822k
Leak: 10092k -> 10087k
Overhead: 44964k -> 44964k
GGC runs: 273
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 120676k -> 120444k
Peak memory use before GGC: 94317k -> 94313k
Peak memory use after GGC: 83911k -> 83907k
Maximum of released memory in single GGC run: 32847k -> 32855k
Garbage: 336328k -> 336378k
Leak: 10108k -> 10106k
Overhead: 45111k -> 45113k
GGC runs: 275
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 118616k
Peak memory use before GGC: 95329k
Peak memory use after GGC: 94374k
Maximum of released memory in single GGC run: 20170k
Garbage: 226620k
Leak: 49361k
Overhead: 36902k
GGC runs: 342
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 573099k to 573947k, overall 0.15%
Amount of memory still referenced at the end of compilation increased from 55611k to 55682k, overall 0.13%
Overall memory needed: 105708k
Peak memory use before GGC: 94383k
Peak memory use after GGC: 93446k
Maximum of released memory in single GGC run: 19454k
Garbage: 573099k -> 573947k
Leak: 55611k -> 55682k
Overhead: 68160k -> 68217k
GGC runs: 490 -> 491
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory needed: 105724k
Peak memory use before GGC: 94383k
Peak memory use after GGC: 93446k
Maximum of released memory in single GGC run: 19454k
Garbage: 647383k -> 647605k
Leak: 56665k -> 56454k
Overhead: 78804k -> 78853k
GGC runs: 547
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory needed: 109652k -> 109532k
Peak memory use before GGC: 95464k
Peak memory use after GGC: 94518k
Maximum of released memory in single GGC run: 19608k
Garbage: 700708k -> 700604k
Leak: 57489k -> 57432k
Overhead: 83551k -> 83615k
GGC runs: 555 -> 553
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-08-13 16:36:01.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-08-14 02:37:19.000000000 +0000
@@ -1,3 +1,57 @@
+2005-08-14 Andreas Schwab <schwab@suse.de>
+
+ * doc/md.texi (Machine Constraints): Fix misplaced @end table.
+
+2005-08-13 James E Wilson <wilson@specifix.com>
+
+ * doc/cpp.texi (__SSP__, __SSP_ALL__): Document.
+ * doc/invoke.texi (-Wstack-protector, -fstack-protector,
+ -fstack-protector-all, --param ssp-buffer-size): Document.
+ (-Wvariadic-macros): Alphabetize.
+ (-fsched-stalled-insns-dep): Add missing 'f'.
+
+ * c-cppbuiltin.c (c_cpp_builtins): Add comment for flag_stack_protect
+ macros.
+
+2005-08-13 David Edelsohn <edelsohn@gnu.org>
+
+ * config/rs6000/rs6000.h (EXTRA_CONSTRAINT): Add 'a' for indexed
+ or indirect address operand.
+ (EXTRA_ADDRESS_CONSTRAINT): New.
+ * config/rs6000/rs6000.md (prefetch): Change constraint "p" to "a".
+
+2005-08-13 Sebastian Pop <pop@cri.ensmp.fr>
+
+ PR tree-optimization/22236
+ * tree-cfg.c (print_pred_bbs, print_succ_bbs): Correctly print
+ successors and predecessors.
+ * tree-chrec.c (chrec_convert): Before converting, check that
+ sequences don't wrap.
+ * tree-data-ref.c (compute_estimated_nb_iterations): Moved ...
+ (analyze_array): Extern.
+ (find_data_references_in_loop): Remove call to
+ compute_estimated_nb_iterations.
+ * tree-data-ref.h (analyze_array): Declared.
+ * tree-flow-inline.h (single_ssa_tree_operand, single_ssa_use_operand,
+ single_ssa_def_operand, zero_ssa_operands): Fix documentation.
+ * tree-flow.h (scev_probably_wraps_p): Declare with an extra parameter.
+ * tree-scalar-evolution.c (instantiate_parameters_1): Factor entry
+ condition.
+ * tree-ssa-loop-ivcanon.c: Fix documentation.
+ * tree-ssa-loop-ivopts.c (idx_find_step): Add a fixme note.
+ * tree-ssa-loop-niter.c (compute_estimated_nb_iterations): ... here.
+ (infer_loop_bounds_from_undefined): New.
+ (estimate_numbers_of_iterations_loop): Use
+ infer_loop_bounds_from_undefined.
+ (used_in_pointer_arithmetic_p): New.
+ (scev_probably_wraps_p): Pass an extra parameter. Call
+ used_in_pointer_arithmetic_p. Check that AT_STMT is not null.
+ (convert_step): Fix documentation.
+ * tree-vrp.c (adjust_range_with_scev): Call instantiate_parameters.
+ Use initial_condition_in_loop_num and evolution_part_in_loop_num
+ instead of CHREC_LEFT and CHREC_RIGHT. Adjust the call to
+ scev_probably_wraps_p.
+
2005-08-13 Ulrich Weigand <uweigand@de.ibm.com>
* config/s390/s390.c (s390_split_branches): Revert 2005-08-12 change.
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.