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]
A recent patch increased GCC's memory consumption!

From: gcctest at suse dot de
To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
Date: Mon, 26 Sep 2005 18:16:50 +0000
Subject: A recent patch increased GCC's memory consumption!
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: 24857k -> 24861k
    Peak memory use before GGC: 9590k
    Peak memory use after GGC: 8937k
    Maximum of released memory in single GGC run: 2737k
    Garbage: 40087k
    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: 60351k
    Leak: 7081k
    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: 2454k
    Garbage: 77828k
    Leak: 7476k
    Overhead: 10110k
    GGC runs: 456

comparing combine.c compilation at -O3 level:
    Overall memory needed: 26812k
    Peak memory use before GGC: 18470k
    Peak memory use after GGC: 18099k
    Maximum of released memory in single GGC run: 3362k
    Garbage: 111028k
    Leak: 7565k
    Overhead: 13941k
    GGC runs: 516

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: 146336k
    Leak: 10091k
    Overhead: 19790k
    GGC runs: 250

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 111884k
    Peak memory use before GGC: 94161k
    Peak memory use after GGC: 83708k
    Maximum of released memory in single GGC run: 32586k
    Garbage: 289963k
    Leak: 10077k
    Overhead: 36650k
    GGC runs: 245

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 126412k
    Peak memory use before GGC: 113391k
    Peak memory use after GGC: 83668k
    Maximum of released memory in single GGC run: 32200k
    Garbage: 376080k
    Leak: 10183k
    Overhead: 48508k
    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: 83696k
    Maximum of released memory in single GGC run: 32515k
    Garbage: 376626k
    Leak: 10199k
    Overhead: 48658k
    GGC runs: 276

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 118652k -> 118636k
    Peak memory use before GGC: 95355k -> 95346k
    Peak memory use after GGC: 94408k -> 94399k
    Maximum of released memory in single GGC run: 20181k -> 20182k
    Garbage: 226865k -> 226845k
    Leak: 49361k
    Overhead: 36910k -> 36908k
    GGC runs: 370

comparing Gerald's testcase PR8361 compilation at -O1 level:
  Peak amount of GGC memory still allocated after garbage collectin increased from 93363k to 93462k, overall 0.11%
    Overall memory needed: 106068k -> 106060k
    Peak memory use before GGC: 95970k -> 95951k
    Peak memory use after GGC: 93363k -> 93462k
    Maximum of released memory in single GGC run: 20659k -> 20648k
    Garbage: 573626k -> 573627k
    Leak: 55650k -> 55649k
    Overhead: 67998k -> 67998k
    GGC runs: 518 -> 517

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Peak amount of GGC memory still allocated after garbage collectin increased from 93363k to 93462k, overall 0.11%
    Overall memory needed: 106808k -> 106696k
    Peak memory use before GGC: 95971k -> 95951k
    Peak memory use after GGC: 93363k -> 93462k
    Maximum of released memory in single GGC run: 20659k -> 20648k
    Garbage: 657123k -> 657014k
    Leak: 56432k -> 56431k
    Overhead: 79383k -> 79381k
    GGC runs: 582 -> 583

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 110304k -> 109916k
    Peak memory use before GGC: 97439k -> 97430k
    Peak memory use after GGC: 94542k -> 94534k
    Maximum of released memory in single GGC run: 21151k
    Garbage: 714479k -> 714297k
    Leak: 57481k -> 57497k
    Overhead: 84503k -> 84507k
    GGC runs: 584 -> 585

Head of the ChangeLog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-09-26 06:52:29.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-09-26 17:07:35.000000000 +0000
@@ -1,3 +1,23 @@
+2005-09-26  J"orn Rennecke <joern.rennecke@st.com>
+
+	* rtlanal.c (reg_used_between_p): Don't check for CLOBBERs in
+	CALL_INSN_FUNCTION_USAGE.
+
+2005-09-26  Richard Guenther  <rguenther@suse.de>
+
+	PR middle-end/15855
+	* gcse.c: Include hashtab.h, define ldst entry hashtable.
+	(pre_ldst_expr_hash, pre_ldst_expr_eq): New functions.
+	(ldst_entry): Use the hashtable instead of list-walking.
+	(find_rtx_in_ldst): Likewise.
+	(free_ldst_entry): Free the hashtable.
+	(compute_ld_motion_mems): Create the hashtable.
+	(trim_ld_motion_mems): Remove entry from hashtable if
+	removing it from list.
+	(compute_store_table): Likewise^2.
+	(store_motion): Free hashtable in case we did not see
+	any stores.
+
 2005-09-25  Kazu Hirata  <kazu@codesourcery.com>
 
 	* fold-const.c (fold_binary): Use op0 and op1 instead of arg0
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2005-09-22 18:44:42.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2005-09-26 17:07:37.000000000 +0000
@@ -1,3 +1,18 @@
+2005-09-26  Richard Guenther  <rguenther@suse.de>
+
+	PR middle-end/15855
+	* decl2.c (do_static_destruction): Remove.
+	(finish_static_initialization_or_destruction): Likewise.
+	(DECL_EFFECTIVE_INIT_PRIORITY): New macro.
+	(NEEDS_GUARD_P): Likewise.
+	(do_static_initialization): Rename to
+	do_static_initialization_or_destruction.  Process all
+	initializers/destructors and handle common conditionalizing.
+	(start_static_initialization_or_destruction): Rename to
+	one_static_initialization_or_destruction.  Handle only
+	decl-specific conditionalizing.
+	(cp_finish_file): Call do_static_initialization_or_destruction.
+
 2005-09-22  Jakub Jelinek  <jakub@redhat.com>
 
 	PR c++/21983


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.
Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]