This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]