GCC memory consumption increased by recent patch!
gcctest@suse.de
gcctest@suse.de
Fri Oct 1 19:35: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: 25269k -> 25265k
Peak memory use before GGC: 9345k
Peak memory use after GGC: 8656k
Maximum of released memory in single GGC run: 2939k
Garbage: 43116k
Leak: 6090k
Overhead: 5694k
GGC runs: 363
comparing combine.c compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 26693k to 26741k, overall 0.18%
Amount of produced GGC garbage increased from 70529k to 73182k, overall 3.76%
Overall memory needed: 26693k -> 26741k
Peak memory use before GGC: 9433k -> 9436k
Peak memory use after GGC: 8869k -> 8872k
Maximum of released memory in single GGC run: 2070k -> 2071k
Garbage: 70529k -> 73182k
Leak: 6673k -> 6677k
Overhead: 11340k -> 11496k
GGC runs: 578 -> 576
comparing combine.c compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 29817k to 29853k, overall 0.12%
Amount of produced GGC garbage increased from 85679k to 88337k, overall 3.10%
Overall memory needed: 29817k -> 29853k
Peak memory use before GGC: 12772k
Peak memory use after GGC: 12612k
Maximum of released memory in single GGC run: 2596k
Garbage: 85679k -> 88337k
Leak: 6427k -> 6431k
Overhead: 15887k -> 16037k
GGC runs: 577 -> 578
comparing combine.c compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 13077k to 13438k, overall 2.76%
Amount of produced GGC garbage increased from 114508k to 118782k, overall 3.73%
Amount of memory still referenced at the end of compilation increased from 6930k to 7032k, overall 1.47%
Overall memory needed: 21428k -> 21448k
Peak memory use before GGC: 13077k -> 13438k
Peak memory use after GGC: 12725k -> 12724k
Maximum of released memory in single GGC run: 3454k
Garbage: 114508k -> 118782k
Leak: 6930k -> 7032k
Overhead: 20982k -> 21241k
GGC runs: 643 -> 642
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 118920k
Peak memory use before GGC: 79664k
Peak memory use after GGC: 46309k
Maximum of released memory in single GGC run: 43569k
Garbage: 163567k
Leak: 10644k
Overhead: 20607k
GGC runs: 307
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 131960k -> 131988k
Peak memory use before GGC: 91605k
Peak memory use after GGC: 70898k
Maximum of released memory in single GGC run: 42250k
Garbage: 465895k -> 465581k
Leak: 11075k
Overhead: 74816k -> 74803k
GGC runs: 462 -> 461
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 210308k -> 210152k
Peak memory use before GGC: 107164k
Peak memory use after GGC: 86457k
Maximum of released memory in single GGC run: 36153k
Garbage: 515187k -> 514976k
Leak: 10957k
Overhead: 82852k -> 82845k
GGC runs: 384
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 210312k -> 210156k
Peak memory use before GGC: 107173k
Peak memory use after GGC: 86466k
Maximum of released memory in single GGC run: 36152k
Garbage: 516075k -> 516353k
Leak: 11011k -> 11011k
Overhead: 83007k -> 83034k
GGC runs: 392 -> 393
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 113448k
Peak memory use before GGC: 90536k
Peak memory use after GGC: 89158k
Maximum of released memory in single GGC run: 20157k
Garbage: 262109k -> 262101k
Leak: 59481k -> 59481k
Overhead: 47301k -> 47300k
GGC runs: 375
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 594371k to 699651k, overall 17.71%
Overall memory needed: 108032k -> 107908k
Peak memory use before GGC: 95134k
Peak memory use after GGC: 88446k
Maximum of released memory in single GGC run: 19483k
Garbage: 594371k -> 699651k
Leak: 61548k -> 61537k
Overhead: 130696k -> 132311k
GGC runs: 605 -> 625
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 646890k to 750849k, overall 16.07%
Overall memory needed: 108412k -> 108368k
Peak memory use before GGC: 95135k
Peak memory use after GGC: 88446k
Maximum of released memory in single GGC run: 19484k
Garbage: 646890k -> 750849k
Leak: 62100k -> 62089k
Overhead: 153551k -> 155126k
GGC runs: 638 -> 661
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 105432k to 113612k, overall 7.76%
Peak amount of GGC memory allocated before garbage collecting increased from 91094k to 99940k, overall 9.71%
Amount of produced GGC garbage increased from 682975k to 848079k, overall 24.17%
Overall memory needed: 105432k -> 113612k
Peak memory use before GGC: 91094k -> 99940k
Peak memory use after GGC: 89672k -> 89670k
Maximum of released memory in single GGC run: 20199k
Garbage: 682975k -> 848079k
Leak: 62521k -> 62506k
Overhead: 162879k -> 165243k
GGC runs: 626 -> 639
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2004-10-01 06:43:43.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2004-10-01 18:27:43.000000000 +0000
@@ -1,3 +1,101 @@
+2004-10-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ * common.opt (ftree-loop-ivcanon): Enable by default.
+ * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely):
+ Enable complete loop unrolling.
+ (canonicalize_induction_variables, tree_unroll_loops_completely):
+ Reset scev info.
+
+2004-01-01 Paul Brook <paul@codesourcery.com>
+
+ * config/arm/arm.c (thumb_compute_saved_rag_mask): Or with bitmask,
+ not register number.
+ (thumb_find_work_register): Search full register range.
+
+2004-10-01 Andrew Pinski <pinskia@physics.uc.edu>
+
+ PR tree-opt/17343
+ * tree-cfg.c (group_case_labels): Get the label and not
+ the case expr for the default case.
+ When the label we looking at is the default, decrement the
+ new_size.
+
+2004-10-01 Jan Hubicka <jh@suse.cz>
+
+ * c-decl.c (c_expand_body): Update call tree_rest_of_compilation.
+ * cgraphunit.c (cgraph_build_static_cdtor): Likewise.
+ * toplev.h (tree_rest_of_compilation): Update prototype.
+ * tree-optimize.c (tree_rest_of_compilation): Kill nested_p argument.
+
+2004-10-01 Kazu Hirata <kazu@cs.umass.edu>
+
+ * tree-cfg.c (cleanup_tree_cfg): Pull a call to
+ cleanup_control_flow() out of the while loop.
+
+2004-10-01 Paolo Bonzini <bonzini@gnu.org>
+
+ * tree-vectorizer.c (vectorizable_operation): Fail unless
+ the mode for the vector type is indeed a vector mode.
+
+2004-10-01 Zdenek Dvorak <dvorakz@suse.cz>
+
+ * tree-chrec.c (chrec_fold_plus_poly_poly, chrec_fold_plus_1,
+ chrec_fold_multiply): Use fold_convert or build_int_cst_type instead
+ of convert.
+ * tree-scalar-evolution.c (compute_overall_effect_of_inner_loop,
+ add_to_evolution, set_nb_iterations_in_loop, follow_ssa_edge_in_rhs,
+ follow_ssa_edge_in_rhs): Ditto.
+ * tree-ssa-loop-ivopts.c (struct iv): Add base_object field.
+ (dump_iv): Dump base_object.
+ (dump_use, dump_cand): Use dump_iv.
+ (determine_base_object): New function.
+ (alloc_iv): Initialize base_object field.
+ (record_use): Clear the ssa_name field of iv.
+ (get_computation_cost_at): Do not use difference of addresses of
+ two different objects.
+ (may_eliminate_iv): Do not require the loop to have just single exit.
+ * tree-ssa-loop-niter.c (zero_p): Do not check for overflows.
+ (nonzero_p): New function.
+ (inverse, number_of_iterations_cond, simplify_using_outer_evolutions,
+ tree_simplify_using_condition, simplify_using_initial_conditions,
+ loop_niter_by_eval, find_loop_niter_by_eval,
+ estimate_numbers_of_iterations_loop, compare_trees,
+ upper_bound_in_type, lower_bound_in_type,
+ can_count_iv_in_wider_type_bound): Use buildN instead of build. Use
+ fold_convert or build_int_cst_type instead of convert. Use (non)zero_p
+ instead of integer_(non)zerop.
+
+2004-10-01 Jakub Jelinek <jakub@redhat.com>
+
+ Revert
+ 2004-09-29 Jakub Jelinek <jakub@redhat.com>
+
+ * tree.h (enum tree_index): Add TI_VA_LIST_GPR_COUNTER_FIELD
+ and TI_VA_LIST_FPR_COUNTER_FIELD.
+ (va_list_gpr_counter_field, va_list_fpr_counter_field): Define.
+ * tree-pass.h (pass_stdarg): Add.
+ * tree-optimize.c (init_tree_optimization_passes): Add pass_stdarg.
+ * tree-stdarg.c: New file.
+ * Makefile.in (OBJS-common): Add tree-stdarg.o.
+ (tree-stdarg.o): Add dependencies.
+ * function.h (struct function): Add va_list_gpr_size and
+ va_list_fpr_size fields.
+ * function.c (allocate_struct_function): Initialize them.
+
+ * config/i386/i386.c (ix86_build_builtin_va_list): Initialize
+ va_list_{g,f}pr_counter_field.
+ (ix86_setup_incoming_varargs): Don't do anything if reg_save
+ area will not be used. Only save registers that tree-stdarg.c
+ detected they need saving.
+ (ix86_va_start): Don't set up fields that won't be used.
+
+ * config/rs6000/rs6000.c (rs6000_build_builtin_va_list): Initialize
+ va_list_{g,f}pr_counter_field.
+ (setup_incoming_varargs): Don't do anything if reg_save
+ area will not be used. Only save registers that tree-stdarg.c
+ detected they need saving.
+ (rs6000_va_start): Don't set up fields that won't be used.
+
2004-09-30 Eric Christopher <echristo@redhat.com>
* dwarf2.h (dwarf_calling_convention): Add enum for renesas
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2004-09-30 16:52:51.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2004-10-01 18:27:45.000000000 +0000
@@ -1,3 +1,7 @@
+2004-10-01 Jan Hubicka <jh@suse.cz>
+
+ * semantics.c (expand_body): Update call of tree_rest_of_compilation.
+
2004-09-30 Nathan Sidwell <nathan@codesourcery.com>
* cp-tree.h (struct lang_decl): Shrink by reordering fields and
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