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]
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: Fri, 18 Feb 2005 00:02:12 +0000
Subject: 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: 24669k
    Peak memory use before GGC: 9358k
    Peak memory use after GGC: 8673k
    Maximum of released memory in single GGC run: 2867k
    Garbage: 41763k
    Leak: 6395k
    Overhead: 5773k
    GGC runs: 327

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25513k -> 25517k
    Peak memory use before GGC: 9237k
    Peak memory use after GGC: 8740k
    Maximum of released memory in single GGC run: 2026k
    Garbage: 60629k
    Leak: 6756k
    Overhead: 9937k
    GGC runs: 501

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29165k -> 29157k
    Peak memory use before GGC: 12670k
    Peak memory use after GGC: 12544k
    Maximum of released memory in single GGC run: 2597k
    Garbage: 78576k
    Leak: 6593k
    Overhead: 13978k
    GGC runs: 510

comparing combine.c compilation at -O3 level:
    Overall memory needed: 31589k
    Peak memory use before GGC: 12773k
    Peak memory use after GGC: 12544k
    Maximum of released memory in single GGC run: 3434k
    Garbage: 105895k
    Leak: 7120k
    Overhead: 18743k
    GGC runs: 577

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114136k
    Peak memory use before GGC: 75034k
    Peak memory use after GGC: 45493k
    Maximum of released memory in single GGC run: 39627k
    Garbage: 153279k
    Leak: 10984k
    Overhead: 19970k
    GGC runs: 273

comparing insn-attrtab.c compilation at -O1 level:
  Overall memory allocated via mmap and sbrk increased from 124152k to 124568k, overall 0.34%
    Overall memory needed: 124152k -> 124568k
    Peak memory use before GGC: 78747k
    Peak memory use after GGC: 70087k
    Maximum of released memory in single GGC run: 40787k
    Garbage: 370669k
    Leak: 11361k
    Overhead: 69439k
    GGC runs: 398

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 138092k
    Peak memory use before GGC: 97758k
    Peak memory use after GGC: 83478k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 484557k
    Leak: 11242k
    Overhead: 84528k
    GGC runs: 342

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 147800k
    Peak memory use before GGC: 97759k
    Peak memory use after GGC: 83480k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 485374k
    Leak: 11279k
    Overhead: 84658k
    GGC runs: 348

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 111028k
    Peak memory use before GGC: 87201k
    Peak memory use after GGC: 85872k
    Maximum of released memory in single GGC run: 19555k
    Garbage: 246842k
    Leak: 55524k
    Overhead: 43327k
    GGC runs: 367

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 103861k -> 103853k
    Peak memory use before GGC: 86089k
    Peak memory use after GGC: 85053k
    Maximum of released memory in single GGC run: 19025k
    Garbage: 436719k
    Leak: 56858k
    Overhead: 65094k
    GGC runs: 513

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 104093k
    Peak memory use before GGC: 86090k
    Peak memory use after GGC: 85053k
    Maximum of released memory in single GGC run: 19026k
    Garbage: 479929k
    Leak: 57425k
    Overhead: 74695k
    GGC runs: 572

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 105133k -> 105129k
    Peak memory use before GGC: 87329k
    Peak memory use after GGC: 85984k
    Maximum of released memory in single GGC run: 19578k
    Garbage: 484720k
    Leak: 57588k
    Overhead: 75314k
    GGC runs: 561

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-02-17 17:42:27.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-02-17 23:03:38.000000000 +0000
@@ -1,3 +1,39 @@
+2005-02-17  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* bt-load.c, cfgloop.c, convert.c, dominance.c, global.c,
+	loop-invariant.c, stmt.c, tree-ssa-forwprop.c,
+	tree-ssa-live.c, tree-ssanames.c, tree-vn.c,
+	config/host-linux.c, config/arm/fpa.md, config/avr/avr.h:
+	Update copyright.
+
+2005-02-17  Roger Sayle  <roger@eyesopen.com>
+
+	PR tree-optimization/19917
+	* tree-eh.c (tree_could_trap_p): Consider calls to weak functions
+	to be potentially trapping.
+
+2005-02-17  Kazu Hirata  <kazu@cs.umass.edu>
+
+	* libgcc2.c, tree-vect-analyze.c: Fix comment typos.
+
+2005-02-17  Andreas Krebbel  <krebbel1@de.ibm.com>
+
+	* builtins.c (expand_builtin_return_addr): Remove tem parameter.
+	tem becomes a local variable which is set to the value of the 
+	back end defined INITIAL_FRAME_ADDRESS macro.
+	(expand_builtin_frame_address): Omit the base parameter to 
+	expand_builtin_return_addr.
+	(expand_builtin_profile_func): Likewise.
+	* config/s390/s390.h (INITIAL_FRAME_ADDRESS_RTX): Define new macro.
+	(DYNAMIC_CHAIN_ADDRESS): Remove the case for the initial frame.
+	* doc/tm.texi: Documentation for INITIAL_FRAME_ADDRESS_RTX added.
+
+2005-02-17  Jakub Jelinek  <jakub@redhat.com>
+
+	* config/s390/s390.c (s390_alloc_pool, s390_free_pool,
+	s390_chunkify_start): Use BITMAP_ALLOC and BITMAP_FREE.
+	* config/frv/frv.c (frv_function_epilogue): Likewise.
+
 2005-02-17  Daniel Berlin  <dberlin@dberlin.org>
 
 	* lambda-code (perfect_nestify): Remove mark/unmark
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2005-02-17 17:42:31.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2005-02-17 23:03:41.000000000 +0000
@@ -1,5 +1,9 @@
 2005-02-17  Alexandre Oliva  <aoliva@redhat.com>
 
+	PR c++/20028
+	* class.c (finish_struct): Initialize TYPE_SIZE_UNIT of a
+	template along with TYPE_SIZE.
+
 	PR c++/20022
 	* semantics.c (perform_deferred_access_checks): Use
 	get_deferred_access_checks to get the top of the stack.

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]