A recent patch increased GCC's memory consumption!

gcctest@suse.de gcctest@suse.de
Wed Jun 8 00:38:00 GMT 2005


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: 25308k
    Peak memory use before GGC: 9665k
    Peak memory use after GGC: 8978k
    Maximum of released memory in single GGC run: 2790k
    Garbage: 42282k
    Leak: 6724k
    Overhead: 5889k
    GGC runs: 328

comparing combine.c compilation at -O1 level:
  Amount of produced GGC garbage increased from 63141k to 63282k, overall 0.22%
    Overall memory needed: 27804k -> 27828k
    Peak memory use before GGC: 9116k
    Peak memory use after GGC: 8758k
    Maximum of released memory in single GGC run: 2204k -> 2138k
    Garbage: 63141k -> 63282k
    Leak: 7107k -> 7112k
    Overhead: 8032k -> 8036k
    GGC runs: 523 -> 525

comparing combine.c compilation at -O2 level:
  Amount of produced GGC garbage increased from 86259k to 86559k, overall 0.35%
    Overall memory needed: 24832k -> 24868k
    Peak memory use before GGC: 18290k
    Peak memory use after GGC: 18109k
    Maximum of released memory in single GGC run: 2524k
    Garbage: 86259k -> 86559k
    Leak: 7095k -> 7098k
    Overhead: 11181k -> 11194k
    GGC runs: 485

comparing combine.c compilation at -O3 level:
  Amount of produced GGC garbage increased from 114863k to 115271k, overall 0.36%
    Overall memory needed: 25084k -> 25096k
    Peak memory use before GGC: 18294k -> 18296k
    Peak memory use after GGC: 18109k
    Maximum of released memory in single GGC run: 3099k -> 3101k
    Garbage: 114863k -> 115271k
    Leak: 7182k -> 7178k
    Overhead: 14797k -> 14848k
    GGC runs: 538

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 85588k
    Peak memory use before GGC: 73387k
    Peak memory use after GGC: 45373k
    Maximum of released memory in single GGC run: 37597k
    Garbage: 153190k
    Leak: 11550k
    Overhead: 19639k
    GGC runs: 268

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 101600k
    Peak memory use before GGC: 76700k
    Peak memory use after GGC: 65854k
    Maximum of released memory in single GGC run: 37075k
    Garbage: 304694k -> 304697k
    Leak: 11611k -> 11612k
    Overhead: 39366k -> 39366k
    GGC runs: 382

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 158284k -> 158280k
    Peak memory use before GGC: 121367k
    Peak memory use after GGC: 92459k
    Maximum of released memory in single GGC run: 32951k
    Garbage: 402976k -> 402986k
    Leak: 11452k -> 11452k
    Overhead: 52241k -> 52242k
    GGC runs: 305 -> 306

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 158296k -> 158300k
    Peak memory use before GGC: 121369k
    Peak memory use after GGC: 92461k
    Maximum of released memory in single GGC run: 32951k
    Garbage: 403742k -> 403800k
    Leak: 11473k -> 11475k
    Overhead: 52366k -> 52371k
    GGC runs: 310 -> 311

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 127340k
    Peak memory use before GGC: 103091k
    Peak memory use after GGC: 102069k
    Maximum of released memory in single GGC run: 21524k
    Garbage: 247513k
    Leak: 53785k
    Overhead: 42958k
    GGC runs: 346

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 121452k
    Peak memory use before GGC: 112534k
    Peak memory use after GGC: 100711k
    Maximum of released memory in single GGC run: 20027k
    Garbage: 661594k -> 662191k
    Leak: 58912k -> 58760k
    Overhead: 91339k -> 91393k
    GGC runs: 514

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Amount of produced GGC garbage increased from 757133k to 758879k, overall 0.23%
  Amount of memory still referenced at the end of compilation increased from 59554k to 59643k, overall 0.15%
    Overall memory needed: 121424k
    Peak memory use before GGC: 112534k
    Peak memory use after GGC: 100711k
    Maximum of released memory in single GGC run: 20027k
    Garbage: 757133k -> 758879k
    Leak: 59554k -> 59643k
    Overhead: 109521k -> 109651k
    GGC runs: 592 -> 595

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Amount of produced GGC garbage increased from 813416k to 815902k, overall 0.31%
    Overall memory needed: 124376k
    Peak memory use before GGC: 115276k
    Peak memory use after GGC: 102537k
    Maximum of released memory in single GGC run: 21386k
    Garbage: 813416k -> 815902k
    Leak: 60882k -> 60885k
    Overhead: 116648k -> 116816k
    GGC runs: 598 -> 601

Head of the ChangeLog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-06-07 19:33:11.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-06-07 23:34:43.000000000 +0000
@@ -1,3 +1,70 @@
+2005-06-08  Zdenek Dvorak  <dvorakz@suse.cz>
+
+	* tree-ssa-loop-ivopts.c (rewrite_use_outer): Unshare the expression
+	before emiting it.
+
+2005-06-07  Eric Christopher  <echristo@redhat.com>
+
+	* config/mips/predicates.md: Revert previous patch.
+
+2005-06-07  Jakub Jelinek  <jakub@redhat.com>
+
+	PR middle-end/21850
+	* tree.c (get_unwidened): Stop at NOP_EXPR/CONVERT_EXPR that convert
+	from vector types.
+
+2005-06-07  Diego Novillo  <dnovillo@redhat.com>
+
+	* tree-ssa-threadupdate.c (struct thread_stats_d): Declare.
+	(thread_stats): New local variable.
+	(redirect_edges): Increment count of threaded edges.
+	(thread_through_all_blocks): Initialize thread_stats.
+	Display number of threaded jumps if TDF_STATS is enabled.
+
+2005-06-07  Kazu Hirata  <kazu@codesourcery.com>
+
+	* sbitmap.h (sbitmap_iter_init): Consistently treat bit_num as
+	the current bit index with no modulo.
+
+2005-06-07  Sebastian Pop  <pop@cri.ensmp.fr>
+
+	PR 18403 and meta PR 21861.
+	* Makefile.in (tree-chrec.o): Depend on CFGLOOP_H and TREE_FLOW_H.
+	* tree-chrec.c: Include cfgloop.h and tree-flow.h.
+	(evolution_function_is_invariant_rec_p,
+	evolution_function_is_invariant_p): New.
+	(chrec_convert): Use an extra parameter AT_STMT for refining the
+	information that is passed down to convert_step.  Integrate the 
+	code that was in count_ev_in_wider_type.
+	* tree-chrec.h (count_ev_in_wider_type): Removed.
+	(chrec_convert): Modify its declaration.
+	(evolution_function_is_invariant_p): Declared.
+	(evolution_function_is_affine_p): Use evolution_function_is_invariant_p.
+	* tree-flow.h (can_count_iv_in_wider_type): Renamed convert_step.
+	(scev_probably_wraps_p): Declared.
+	* tree-scalar-evolution.c (count_ev_in_wider_type): Removed.
+	(follow_ssa_edge_in_rhs, interpret_rhs_modify_expr):
+	Use an extra parameter AT_STMT for refining the information that is
+	passed down to convert_step.
+	(follow_ssa_edge_inner_loop_phi, follow_ssa_edge,
+	analyze_scalar_evolution_1): Initialize AT_STMT with the current
+	analyzed statement.
+	(instantiate_parameters_1): Don't know yet how to initialize AT_STMT.
+	* tree-ssa-loop-ivopts.c (idx_find_step): Update the use of 
+	can_count_iv_in_wider_type to use convert_step.
+	* tree-ssa-loop-niter.c (can_count_iv_in_wider_type_bound): Move 
+	code that is independent of the loop over the known iteration
+	bounds to convert_step_widening, the rest is moved to
+	proved_non_wrapping_p.
+	(scev_probably_wraps_p): New.
+	(can_count_iv_in_wider_type): Renamed convert_step.
+	* tree-vrp.c (adjust_range_with_scev): Take an extra AT_STMT parameter.
+	Use scev_probably_wraps_p for computing init_is_max.
+	(vrp_visit_assignment): Pass the current analyzed statement to 
+	adjust_range_with_scev.
+	(execute_vrp): Call estimate_numbers_of_iterations for refining the 
+	information provided by scev analyzer.
+
 2005-06-07  Eric Christopher  <echristo@redhat.com>
 
 	* config/mips/predicates.md (sleu_operand): Use


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.



More information about the Gcc-regression mailing list