GCC memory consumption increased by recent patch!

gcctest@suse.de gcctest@suse.de
Wed Dec 15 18:49:00 GMT 2004


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: 24577k -> 24581k
    Peak memory use before GGC: 9310k
    Peak memory use after GGC: 8624k
    Maximum of released memory in single GGC run: 2912k
    Garbage: 42433k
    Leak: 6088k
    Overhead: 5717k
    GGC runs: 353

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25625k -> 25637k
    Peak memory use before GGC: 9198k
    Peak memory use after GGC: 8720k
    Maximum of released memory in single GGC run: 2060k
    Garbage: 68024k
    Leak: 6484k
    Overhead: 10667k
    GGC runs: 545

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29321k -> 29305k
    Peak memory use before GGC: 12705k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 2574k
    Garbage: 82249k
    Leak: 6301k
    Overhead: 14829k
    GGC runs: 547

comparing combine.c compilation at -O3 level:
    Overall memory needed: 20724k
    Peak memory use before GGC: 12987k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 3408k
    Garbage: 111192k
    Leak: 6848k
    Overhead: 19907k
    GGC runs: 614

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 118468k
    Peak memory use before GGC: 79386k
    Peak memory use after GGC: 46137k
    Maximum of released memory in single GGC run: 43335k
    Garbage: 161980k
    Leak: 10609k
    Overhead: 21242k
    GGC runs: 296

comparing insn-attrtab.c compilation at -O1 level:
  Overall memory allocated via mmap and sbrk increased from 129020k to 129432k, overall 0.32%
    Overall memory needed: 129020k -> 129432k
    Peak memory use before GGC: 83952k
    Peak memory use after GGC: 70040k
    Maximum of released memory in single GGC run: 41104k
    Garbage: 445754k
    Leak: 10955k
    Overhead: 79294k
    GGC runs: 430

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 153912k
    Peak memory use before GGC: 99964k
    Peak memory use after GGC: 85453k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 492646k
    Leak: 10875k
    Overhead: 87569k
    GGC runs: 364

comparing insn-attrtab.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 153636k to 153920k, overall 0.18%
    Overall memory needed: 153636k -> 153920k
    Peak memory use before GGC: 99966k
    Peak memory use after GGC: 85455k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 493925k
    Leak: 10920k
    Overhead: 87750k
    GGC runs: 372

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 113400k
    Peak memory use before GGC: 89919k
    Peak memory use after GGC: 89025k
    Maximum of released memory in single GGC run: 19896k
    Garbage: 248727k
    Leak: 57791k
    Overhead: 45380k
    GGC runs: 362

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88916k
    Peak memory use after GGC: 87943k
    Maximum of released memory in single GGC run: 19402k
    Garbage: 552642k
    Leak: 59827k
    Overhead: 115285k
    GGC runs: 612

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88916k
    Peak memory use after GGC: 87943k
    Maximum of released memory in single GGC run: 19401k
    Garbage: 601971k
    Leak: 60409k
    Overhead: 137370k
    GGC runs: 651

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 98436k
    Peak memory use before GGC: 90313k
    Peak memory use after GGC: 88776k
    Maximum of released memory in single GGC run: 20091k
    Garbage: 641871k
    Leak: 60739k
    Overhead: 148762k
    GGC runs: 646

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-12-15 08:38:19.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-12-15 17:45:26.000000000 +0000
@@ -1,5 +1,74 @@
 2004-12-15  Richard Henderson  <rth@redhat.com>
 
+	PR target/19010
+	* config/i386/i386.c (ix86_must_pass_in_stack): Don't return true
+	for TImode vectors.
+	(gen_reg_or_parallel): New.
+	(function_arg): Use it.
+	(ix86_hard_regno_mode_ok): Test SSE1 and SSE2 separately,
+	MMX and 3DNOW separately.
+	(ix86_rtx_costs): Simplify FLOAT_EXTEND case.
+	(ix86_vector_mode_supported_p): Test SSE1 and SSE2 separately.
+	* config/i386/i386.h (VALID_SSE2_REG_MODE): Move SSE2 cases from ...
+	(VALID_SSE_REG_MODE): ... here.
+
+2004-12-15  David Edelsohn  <edelsohn@gnu.org>
+
+	* xcoffout.c (xcoffout_declare_function): Change strncpy to memcpy.
+
+2004-12-15  Ian Lance Taylor  <ian@wasabisystems.com>
+
+	* config/arm/arm.c (arm_xscale_rtx_costs): Increase cost of
+	COMPARE of MULT.
+	* config/arm/arm.md (mulsi3_compare0): Don't check
+	arm_arch_xscale.
+	(mulsi_compare0_scratch, mulsi3_addsi_compare0): Likewise.
+	(mulsi3addsi_compare0_scratch): Likewise.
+
+2004-12-15  Eric Botcazou  <ebotcazou@libertysurf.fr>
+
+	PR other/18665
+	* libgcc-std.ver (GCC_3.4.4): Inherit from GCC_3.4.2.
+	Export __absvti2, __addvti3, __mulvti3, __negvti2 and __subvti3.
+	* libgcc2.c (__addvsi3): Rename to __addvSI3.
+	New version if COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(__addvdi3): Rename to __addvDI3.
+	(__subvsi3): Rename to __subvSI3.  Use word type for the result.
+	New version if COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(__subvdi3): Rename to __subvDI3.
+	(_mulvsi3): Rename to _mulvSI3.
+	New version if COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(_mulvdi3): Rename to _mulvDI3.
+	(__negvsi2): Rename to __negvSI2.
+	New version if COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(__negvdi2): Rename to __negvDI2.
+	(__absvsi2): Rename to __absvSI2.
+	New version if COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(__absvdi2): Rename to __absvDI2.
+	* libgcc2.h (64-bit targets): Define COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+	(__absvSI2, __addvSI3, __subvSI3, __mulvSI3, __negvSI2, __absvDI2,
+	__addvDI3, __subvDI3, __mulvDI3, __negvDI2): Define to the appropriate
+	symbol and declare.
+	(__absvsi2, __addvsi3, __subvsi3, __mulvsi3, __negvsi2): Declare if
+	COMPAT_SIMODE_TRAPPING_ARITHMETIC.
+
+2004-12-15  Kazuhiro Inaoka <inaoka.kazuhiro@reneasas.com>
+
+	* config/m32r/m32r.h (PREFERRED_DEBUGGING_TYPE):
+	Use DWARF2_DEBUG.
+
+	* config/m32r.c (m32r_legitimize_pic_address): Changed
+	to support GOTOFF relocation.
+	* config/m32r.md (UNSPEC_GOTOFF): New.
+	(gotoff_load_addr): New.
+
+2004-12-15  Richard Sandiford  <rsandifo@redhat.com>
+
+	* config/mips/mips.c (mips_arg_info): Use FUNCTION_ARG_BOUNDARY to
+	decide whether an argument is double-word aligned.
+
+2004-12-15  Richard Henderson  <rth@redhat.com>
+
 	* config/i386/i386.md: Fix missing modes on cmove splitters.
 
 2004-12-15 Jan Beulich  <jbeulich@novell.com>
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2004-12-15 03:09:10.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2004-12-15 17:45:30.000000000 +0000
@@ -1,3 +1,17 @@
+2004-12-15  Kriang Lerdsuwanakij  <lerdsuwa@users.sourceforge.net>
+
+	PR c++/18825
+	* pt.c (instantiate_class_template): Set input_location for
+	friend function.
+	(tsubst_friend_function): Don't set input_location here.
+	Make sure the context is complete if necessary.
+
+2004-12-15  Nathan Sidwell  <nathan@codesourcery.com>
+
+	PR c++/18981
+	* parser.c (cp_parser_lookup_name): Remove unneeded TYPENAME_TYPE
+	flag setting.
+
 2004-12-14  Mark Mitchell  <mark@codesourcery.com>
 
 	PR c++/18738

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.



More information about the Gcc-regression mailing list