A recent patch increased GCC's memory consumption!

gcctest@suse.de gcctest@suse.de
Wed Sep 7 09:25: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: 24845k
    Peak memory use before GGC: 9590k
    Peak memory use after GGC: 8937k
    Maximum of released memory in single GGC run: 2737k
    Garbage: 40070k
    Leak: 6698k
    Overhead: 5787k
    GGC runs: 316

comparing combine.c compilation at -O1 level:
    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: 60355k
    Leak: 7083k
    Overhead: 7591k
    GGC runs: 385

comparing combine.c compilation at -O2 level:
    Overall memory needed: 26812k
    Peak memory use before GGC: 17361k
    Peak memory use after GGC: 17173k
    Maximum of released memory in single GGC run: 2455k
    Garbage: 77900k
    Leak: 7475k
    Overhead: 10122k
    GGC runs: 456

comparing combine.c compilation at -O3 level:
    Overall memory needed: 26812k
    Peak memory use before GGC: 18479k
    Peak memory use after GGC: 18109k
    Maximum of released memory in single GGC run: 3367k
    Garbage: 111067k
    Leak: 7559k
    Overhead: 13954k
    GGC runs: 515

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 80920k
    Peak memory use before GGC: 69464k
    Peak memory use after GGC: 45002k
    Maximum of released memory in single GGC run: 36248k
    Garbage: 146330k
    Leak: 10091k
    Overhead: 19790k
    GGC runs: 250

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 111892k
    Peak memory use before GGC: 94163k
    Peak memory use after GGC: 83710k
    Maximum of released memory in single GGC run: 32587k
    Garbage: 290090k
    Leak: 10078k
    Overhead: 36722k
    GGC runs: 245

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 126412k
    Peak memory use before GGC: 113394k
    Peak memory use after GGC: 83672k
    Maximum of released memory in single GGC run: 32273k
    Garbage: 376159k
    Leak: 10190k
    Overhead: 48542k
    GGC runs: 274

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 126456k
    Peak memory use before GGC: 113417k
    Peak memory use after GGC: 83695k
    Maximum of released memory in single GGC run: 32590k
    Garbage: 376726k
    Leak: 10199k
    Overhead: 48692k
    GGC runs: 276

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 118612k -> 118648k
    Peak memory use before GGC: 95329k -> 95354k
    Peak memory use after GGC: 94374k -> 94408k
    Maximum of released memory in single GGC run: 20170k -> 20180k
    Garbage: 226778k -> 226810k
    Leak: 49361k
    Overhead: 36907k -> 36906k
    GGC runs: 370 -> 369

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 106060k -> 106104k
    Peak memory use before GGC: 95934k -> 95970k
    Peak memory use after GGC: 93445k -> 93362k
    Maximum of released memory in single GGC run: 20638k -> 20659k
    Garbage: 574172k -> 573776k
    Leak: 55683k -> 55637k
    Overhead: 68219k -> 68086k
    GGC runs: 517 -> 515

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 106752k -> 106828k
    Peak memory use before GGC: 95934k -> 95970k
    Peak memory use after GGC: 93446k -> 93363k
    Maximum of released memory in single GGC run: 20638k -> 20659k
    Garbage: 659309k -> 657718k
    Leak: 56476k -> 56416k
    Overhead: 79690k -> 79559k
    GGC runs: 580 -> 582

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Amount of produced GGC garbage increased from 713464k to 715093k, overall 0.23%
    Overall memory needed: 110564k -> 109796k
    Peak memory use before GGC: 97413k -> 97438k
    Peak memory use after GGC: 94517k -> 94541k
    Maximum of released memory in single GGC run: 21141k -> 21150k
    Garbage: 713464k -> 715093k
    Leak: 57453k -> 57447k
    Overhead: 84544k -> 84725k
    GGC runs: 586 -> 585

Head of the ChangeLog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-09-07 03:39:47.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-09-07 08:15:07.000000000 +0000
@@ -1,3 +1,61 @@
+2005-09-07  Andreas Krebbel  <krebbel1@de.ibm.com>
+
+	* reload1.c (fixup_eh_region_note): Remove assertion.
+	(fixup_abnormal_edges): Reverted removal of call to 
+	find_many_sub_basic_blocks made on 2005-08-31.
+
+2005-09-07  Richard Henderson  <rth@redhat.com>
+
+        * function.c (ARG_POINTER_CFA_OFFSET): Move ...
+        * defaults.h (ARG_POINTER_CFA_OFFSET): ... here.
+	(INCOMING_FRAME_SP_OFFSET): Move from dwarf2out.c.
+        * dwarf2out.c (struct cfa_loc): Change reg to unsigned int,
+        rearrange for better packing.
+	(INCOMING_FRAME_SP_OFFSET): Move to defaults.h.
+        (lookup_cfa_1): Remove inline marker.
+        (cfa_equal_p): Split out of ...
+        (def_cfa_1): ... here.  Use INVALID_REGNUM.
+        (build_cfa_loc): Handle !cfa->indirect.
+        (frame_pointer_cfa_offset): New.
+        (dbx_reg_number): Assert register elimination performed; do
+        leaf register remapping.
+        (reg_loc_descriptor): Avoid calling dbx_reg_number when unused.
+        (eliminate_reg_to_offset): New.
+        (based_loc_descr): Remove can_use_fbreg argument.  Use fbreg only
+        for verifiably local stack frame addresses; re-base to CFA.
+        (mem_loc_descriptor): Remove can_use_fbreg argument.
+        (concat_loc_descriptor, loc_descriptor): Likewise.
+        (containing_function_has_frame_base): Remove.
+        (rtl_for_decl_location): Don't do register elimination or
+        leaf register remapping here.
+        (secname_for_decl): Split out from ..
+        (add_location_or_const_value_attribute): ... here.
+        (convert_cfa_to_loc_list): New.
+        (compute_frame_pointer_to_cfa_displacement): New.
+        (gen_subprogram_die): Use them.
+        * tree.h (frame_base_decl): Remove.
+        * var-tracking.c (frame_base_decl, frame_stack_adjust): Remove.
+        (prologue_stack_adjust): Remove.
+        (vt_stack_adjustments): Use INCOMING_FRAME_SP_OFFSET.
+        (adjust_stack_reference): Re-base memories to arg_pointer_rtx.
+        (set_frame_base_location): Remove.
+        (compute_bb_dataflow, emit_notes_in_bb): Don't call it.
+        (dump_attrs_list, dump_dataflow_set): Use string concatenation.
+        (vt_add_function_parameters): Don't eliminate_regs.
+        (vt_initialize): Don't create frame_base_decl.
+
+2005-09-07  Eric Botcazou  <ebotcazou@libertysurf.fr>
+
+	* doc/install.texi (*-*-solaris2*): Clarify wording on the recommended
+	version of GNU binutils for 4.x and later.
+
+2005-09-06  Mark Mitchell  <mark@codesourcery.com>
+
+	* ggc-page.c (ggc_push_context): Remove.
+	(ggc_pop_context): Likewise.
+	* ggc.h (ggc_push_context): Remove.
+	(ggc_pop_context): Likewise.
+
 2005-09-06  Saurabh Verma  <saurabh.verma@codito.com>
 
 	PR target/8973
@@ -3918,7 +3976,7 @@
 	* tree-ssa-structalias.c (need_to_solve): Need to check for preds,
 	too.
 
-2005-07-16  Eric Botcazou <ebotcazou@libertysurf.fr>
+2005-07-16  Eric Botcazou  <ebotcazou@libertysurf.fr>
 
 	* doc/install.texi (*-*-solaris2*): Document recommended version
 	of GNU binutils and mention GNU linker problem on Solaris 10.
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2005-09-07 03:39:49.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2005-09-07 08:15:11.000000000 +0000
@@ -1,3 +1,8 @@
+2005-09-07  Richard Guenther  <rguenther@suse.de>
+
+	* cp-gimplify.c (cp_gimplify_expr): Create empty CONSTRUCTOR
+	for EMPTY_CLASS_EXPR.
+
 2005-09-06  Jakub Jelinek  <jakub@redhat.com>
 
 	PR c/23075


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