This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
Some aspect of GCC memory consumption increased by recent patch
- From: gcctest at suse dot de
- To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
- Date: Sun, 13 Mar 2005 09:32:42 +0000
- Subject: Some aspect of GCC memory consumption increased by recent patch
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: 24665k -> 24677k
Peak memory use before GGC: 9358k
Peak memory use after GGC: 8672k
Maximum of released memory in single GGC run: 2864k
Garbage: 41686k
Leak: 6394k
Overhead: 5770k
GGC runs: 327
comparing combine.c compilation at -O1 level:
Peak amount of GGC memory still allocated after garbage collectin increased from 8093k to 8116k, overall 0.28%
Amount of produced GGC garbage increased from 58308k to 61738k, overall 5.88%
Overall memory needed: 24477k -> 24821k
Peak memory use before GGC: 8667k -> 8669k
Peak memory use after GGC: 8093k -> 8116k
Maximum of released memory in single GGC run: 2021k -> 2023k
Garbage: 58308k -> 61738k
Leak: 6753k -> 6759k
Overhead: 9834k -> 10113k
GGC runs: 501 -> 528
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 78894k to 82779k, overall 4.92%
Overall memory needed: 28889k -> 29193k
Peak memory use before GGC: 12670k
Peak memory use after GGC: 12544k
Maximum of released memory in single GGC run: 2596k
Garbage: 78894k -> 82779k
Leak: 6589k -> 6595k
Overhead: 14262k -> 14782k
GGC runs: 522 -> 536
comparing combine.c compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 12715k to 12747k, overall 0.25%
Amount of produced GGC garbage increased from 106697k to 112209k, overall 5.17%
Amount of memory still referenced at the end of compilation increased from 7195k to 7203k, overall 0.11%
Overall memory needed: 30805k -> 31113k
Peak memory use before GGC: 12715k -> 12747k
Peak memory use after GGC: 12544k
Maximum of released memory in single GGC run: 3423k
Garbage: 106697k -> 112209k
Leak: 7195k -> 7203k
Overhead: 19107k -> 19557k
GGC runs: 583 -> 610
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 114212k
Peak memory use before GGC: 74821k
Peak memory use after GGC: 45493k
Maximum of released memory in single GGC run: 39414k
Garbage: 152812k
Leak: 10983k
Overhead: 19968k
GGC runs: 273
comparing insn-attrtab.c compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 78641k to 78893k, overall 0.32%
Peak amount of GGC memory still allocated after garbage collectin increased from 70035k to 70288k, overall 0.36%
Amount of produced GGC garbage increased from 369231k to 370307k, overall 0.29%
Overall memory needed: 124760k -> 123248k
Peak memory use before GGC: 78641k -> 78893k
Peak memory use after GGC: 70035k -> 70288k
Maximum of released memory in single GGC run: 40773k -> 40782k
Garbage: 369231k -> 370307k
Leak: 11360k -> 11362k
Overhead: 71914k -> 72801k
GGC runs: 400 -> 402
comparing insn-attrtab.c compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 147448k to 151172k, overall 2.53%
Peak amount of GGC memory allocated before garbage collecting increased from 97673k to 97926k, overall 0.26%
Peak amount of GGC memory still allocated after garbage collectin increased from 83493k to 83745k, overall 0.30%
Amount of produced GGC garbage increased from 489762k to 490849k, overall 0.22%
Overall memory needed: 147448k -> 151172k
Peak memory use before GGC: 97673k -> 97926k
Peak memory use after GGC: 83493k -> 83745k
Maximum of released memory in single GGC run: 39453k
Garbage: 489762k -> 490849k
Leak: 11240k -> 11242k
Overhead: 87471k -> 88354k
GGC runs: 343 -> 344
comparing insn-attrtab.c compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 97675k to 97932k, overall 0.26%
Peak amount of GGC memory still allocated after garbage collectin increased from 83495k to 83751k, overall 0.31%
Amount of produced GGC garbage increased from 490574k to 491706k, overall 0.23%
Overall memory needed: 148972k -> 151176k
Peak memory use before GGC: 97675k -> 97932k
Peak memory use after GGC: 83495k -> 83751k
Maximum of released memory in single GGC run: 39453k
Garbage: 490574k -> 491706k
Leak: 11277k -> 11288k
Overhead: 87601k -> 88521k
GGC runs: 349 -> 351
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 111956k
Peak memory use before GGC: 87327k
Peak memory use after GGC: 85902k
Maximum of released memory in single GGC run: 19511k
Garbage: 246348k
Leak: 55514k
Overhead: 43272k
GGC runs: 366
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 435007k to 464694k, overall 6.82%
Amount of memory still referenced at the end of compilation increased from 56860k to 59197k, overall 4.11%
Overall memory needed: 104029k -> 104229k
Peak memory use before GGC: 86185k
Peak memory use after GGC: 85120k
Maximum of released memory in single GGC run: 18950k
Garbage: 435007k -> 464694k
Leak: 56860k -> 59197k
Overhead: 65155k -> 72216k
GGC runs: 513 -> 548
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 477960k to 520141k, overall 8.83%
Amount of memory still referenced at the end of compilation increased from 57428k to 59776k, overall 4.09%
Overall memory needed: 104253k -> 105497k
Peak memory use before GGC: 86185k
Peak memory use after GGC: 85121k
Maximum of released memory in single GGC run: 18950k
Garbage: 477960k -> 520141k
Leak: 57428k -> 59776k
Overhead: 75178k -> 90394k
GGC runs: 568 -> 610
comparing Gerald's testcase PR8361 compilation at -O3 level:
Ovarall memory allocated via mmap and sbrk decreased from 105353k to 97052k, overall -8.55%
Amount of produced GGC garbage increased from 483127k to 523891k, overall 8.44%
Amount of memory still referenced at the end of compilation increased from 57613k to 59956k, overall 4.07%
Overall memory needed: 105353k -> 97052k
Peak memory use before GGC: 87324k
Peak memory use after GGC: 86200k
Maximum of released memory in single GGC run: 19399k
Garbage: 483127k -> 523891k
Leak: 57613k -> 59956k
Overhead: 75845k -> 90167k
GGC runs: 558 -> 591
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-03-12 23:17:08.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-03-13 08:30:28.000000000 +0000
@@ -1,3 +1,79 @@
+2005-03-13 Kazu Hirata <kazu@cs.umass.edu>
+
+ * builtins.c (fold_builtin_classify): Take decomposed
+ arguments of CALL_EXPR.
+ (fold_builtin_1): Update a call to fold_builtin_classify.
+
+2005-03-13 Joseph S. Myers <joseph@codesourcery.com>
+
+ PR c/20402
+ * c-parser.c (c_parser_struct_or_union_specifier): Don't fall
+ through into call to parser_xref_tag after parse error.
+ (c_parser_struct_declaration): Consistently return NULL_TREE on
+ error.
+
+2005-03-12 Daniel Berlin <dberlin@dberlin.org>
+
+ * tree-flow-inline.h (ref_contains_array_ref): New function.
+ (lookup_subvars_for_var): Ditto.
+ (get_subvars_for_var): Ditto.
+ (var_can_have_subvars): Ditto.
+
+ * tree-flow.h (mem_tag_kind): Add STRUCT_FIELD.
+ (struct subvar): New type.
+
+ * tree-dfa.c (okay_component_ref_for_subvars): New function.
+
+ * tree-optimize.c (init_tree_optimization_passes): Call
+ pass_create_structure_vars.
+
+ * tree-ssa-alias.c: Include vec.h.
+ (init_alias_info): Don't auto-clear call clobbered on struct-field
+ tags.
+ (compute_flow_insensitive_aliasing): Handle subvars.
+ (group_aliases): Handle STRUCT_FIELD aliases.
+ (setup_pointers_and_addressables): Ditto.
+ Don't mark variables non-addressable if they still have
+ addressable subvars.
+ Also mark subvars addressable when the real variable is marked
+ addressable.
+ (add_pointed_to_var): Try to prune the pointed-to set by only
+ pointing to subvars when possible.
+ Otherwise, make sure we set addresses_needed and pt_vars to
+ properly include subvars.
+ (bitpos_of_field): New function.
+ (push_fields_onto_fieldstack): Ditto.
+ (get_or_create_used_part_for): Ditto.
+ (create_overlap_variables_for): Ditto.
+ (find_used_portions): Ditto.
+ (create_structure_vars): Ditto.
+ (pass_create_structure_vars): New structure.
+
+ * tree-ssa-operands.c (finalize_ssa_v_must_defs): Remove assert.
+ (get_expr_operands): Handle subvars. Also try to turn
+ COMPONENT_REF accesses into must-defs now that we can accurately
+ portray it.
+ (note_addressable): Try to only mark as addressable those subvars
+ we know a COMPONENT_REF touches.
+ (overlap_subvar): New function.
+
+ * tree-vect-analyze.c (vect_object_analysis): Add new parameter.
+ Handle subvar storing.
+ (vect_address_analysis): Update caller of vect_object_analysis.
+
+ * tree-vect-transform.c (vect_create_data_ref_ptr): Copy subvars.
+
+ * tree-vectorizer.h (struct _stmt_vec_info): Add subvars member.
+ (STMT_VINFO_SUBVARS): New macro.
+
+ * common.opts: add flag_tree_salias.
+
+ * opts.c (decode_options): flag_tree_salias defaults to on.
+
+ * doc/invoke.texi: Document fdump-tree-svars and -ftree-salias.
+
+ * doc/tree-ssa.texi: Document structural alias analysis.
+
2005-03-12 Steven Bosscher <stevenb@suse.de>
* tree-cfg.c (make_goto_expr_edges): Don't use error_mark_node.
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.