Some aspect of GCC memory consumption increased by recent patch

gcctest@suse.de gcctest@suse.de
Thu Dec 23 07:53: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:
  Amount of memory still referenced at the end of compilation decreased from 6198k to 5862k, overall -5.74%
    Overall memory needed: 24569k -> 24373k
    Peak memory use before GGC: 9310k -> 9062k
    Peak memory use after GGC: 8624k -> 8376k
    Maximum of released memory in single GGC run: 2912k -> 2864k
    Garbage: 42635k -> 41733k
    Leak: 6198k -> 5862k
    Overhead: 6027k -> 5544k
    GGC runs: 352

comparing combine.c compilation at -O1 level:
  Amount of memory still referenced at the end of compilation decreased from 6594k to 6257k, overall -5.37%
    Overall memory needed: 25533k -> 25349k
    Peak memory use before GGC: 9195k -> 8953k
    Peak memory use after GGC: 8693k -> 8449k
    Maximum of released memory in single GGC run: 2060k -> 2027k
    Garbage: 68168k -> 67063k
    Leak: 6594k -> 6257k
    Overhead: 10966k -> 10336k
    GGC runs: 544 -> 545

comparing combine.c compilation at -O2 level:
  Amount of memory still referenced at the end of compilation decreased from 6410k to 6081k, overall -5.40%
    Overall memory needed: 29081k -> 28825k
    Peak memory use before GGC: 12705k -> 12382k
    Peak memory use after GGC: 12578k -> 12257k
    Maximum of released memory in single GGC run: 2574k -> 2532k
    Garbage: 82146k -> 80994k
    Leak: 6410k -> 6081k
    Overhead: 14851k -> 14149k
    GGC runs: 545 -> 547

comparing combine.c compilation at -O3 level:
  Amount of memory still referenced at the end of compilation decreased from 6959k to 6588k, overall -5.63%
    Overall memory needed: 31449k -> 31205k
    Peak memory use before GGC: 12987k -> 12657k
    Peak memory use after GGC: 12578k -> 12257k
    Maximum of released memory in single GGC run: 3407k -> 3350k
    Garbage: 111174k -> 109641k
    Leak: 6959k -> 6588k
    Overhead: 19920k -> 19051k
    GGC runs: 613 -> 615

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 118468k -> 117264k
    Peak memory use before GGC: 79387k -> 77778k
    Peak memory use after GGC: 46137k -> 45258k
    Maximum of released memory in single GGC run: 43336k -> 42606k
    Garbage: 162685k -> 159295k
    Leak: 10695k -> 10432k
    Overhead: 22022k -> 20571k
    GGC runs: 296 -> 294

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 129456k -> 128492k
    Peak memory use before GGC: 83952k -> 83296k
    Peak memory use after GGC: 70040k -> 69015k
    Maximum of released memory in single GGC run: 41104k -> 40617k
    Garbage: 446676k -> 441511k
    Leak: 11042k -> 10778k
    Overhead: 80301k -> 77180k
    GGC runs: 430 -> 431

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 154072k -> 153136k
    Peak memory use before GGC: 99964k -> 99059k
    Peak memory use after GGC: 85453k -> 84179k
    Maximum of released memory in single GGC run: 42091k -> 41527k
    Garbage: 493569k -> 488015k
    Leak: 10961k -> 10710k
    Overhead: 88576k -> 85274k
    GGC runs: 364 -> 363

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 153924k -> 153132k
    Peak memory use before GGC: 99966k -> 99061k
    Peak memory use after GGC: 85455k -> 84181k
    Maximum of released memory in single GGC run: 42091k -> 41527k
    Garbage: 494834k -> 489288k
    Leak: 11004k -> 10752k
    Overhead: 88742k -> 85439k
    GGC runs: 372 -> 373

comparing Gerald's testcase PR8361 compilation at -O0 level:
  Peak amount of GGC memory allocated before garbage collecting run decreased from 89921k to 86774k, overall -3.63%
  Peak amount of GGC memory still allocated after garbage collecting decreased from 89026k to 85805k, overall -3.75%
  Amount of memory still referenced at the end of compilation decreased from 58584k to 54799k, overall -6.91%
    Overall memory needed: 113408k -> 110968k
    Peak memory use before GGC: 89921k -> 86774k
    Peak memory use after GGC: 89026k -> 85805k
    Maximum of released memory in single GGC run: 19894k -> 19367k
    Garbage: 249415k -> 243357k
    Leak: 58584k -> 54799k
    Overhead: 46715k -> 42371k
    GGC runs: 362 -> 366

comparing Gerald's testcase PR8361 compilation at -O1 level:
  Peak amount of GGC memory allocated before garbage collecting run decreased from 88922k to 85786k, overall -3.66%
  Peak amount of GGC memory still allocated after garbage collecting decreased from 87937k to 84867k, overall -3.62%
  Amount of memory still referenced at the end of compilation decreased from 60623k to 56768k, overall -6.79%
    Overall memory needed: 106209k -> 103873k
    Peak memory use before GGC: 88922k -> 85786k
    Peak memory use after GGC: 87937k -> 84867k
    Maximum of released memory in single GGC run: 19407k -> 18961k
    Garbage: 485830k -> 474861k
    Leak: 60623k -> 56768k
    Overhead: 73725k -> 67514k
    GGC runs: 552 -> 557

comparing Gerald's testcase PR8361 compilation at -O2 level:
  Peak amount of GGC memory allocated before garbage collecting run decreased from 88923k to 85786k, overall -3.66%
  Peak amount of GGC memory still allocated after garbage collecting decreased from 87938k to 84868k, overall -3.62%
  Amount of memory still referenced at the end of compilation decreased from 61205k to 57349k, overall -6.73%
    Overall memory needed: 106269k -> 103933k
    Peak memory use before GGC: 88923k -> 85786k
    Peak memory use after GGC: 87938k -> 84868k
    Maximum of released memory in single GGC run: 19408k -> 18961k
    Garbage: 520604k -> 509576k
    Leak: 61205k -> 57349k
    Overhead: 83386k -> 77008k
    GGC runs: 591 -> 608

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 107909k to 111569k, overall 3.39%
  Peak amount of GGC memory allocated before garbage collecting increased from 90319k to 92546k, overall 2.47%
  Peak amount of GGC memory still allocated after garbage collecting decreased from 88770k to 86104k, overall -3.10%
  Amount of memory still referenced at the end of compilation decreased from 61549k to 57706k, overall -6.66%
    Overall memory needed: 107909k -> 111569k
    Peak memory use before GGC: 90319k -> 92546k
    Peak memory use after GGC: 88770k -> 86104k
    Maximum of released memory in single GGC run: 20097k -> 19786k
    Garbage: 541418k -> 530012k
    Leak: 61549k -> 57706k
    Overhead: 85193k -> 78698k
    GGC runs: 576 -> 586

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-12-23 02:20:41.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-12-23 06:52:12.000000000 +0000
@@ -1,3 +1,33 @@
+2004-12-22  Richard Henderson  <rth@redhat.com>
+
+	* config/i386/predicates.md (sse_comparison_operator): Fix
+	typo in ieee test.
+	(arith_or_logical_operator): Downcase codes.
+
+2004-12-23  Kaz Kojima  <kkojima@gcc.gnu.org>
+
+	PR target/18511
+	* reload1.c (emit_output_reload_insns): Check if OLD is a hard
+	register before calling regno_clobbered_p.
+	* reload.c: Update comment for regno_clobbered_p.
+
+2004-12-22  Richard Henderson  <rth@redhat.com>
+
+	* config/i386/i386.c (override_options): Respect user disable of
+	fancy 387 math, sse, mmx.
+	(construct_container): Generate error if we need an sse regster
+	and sse has been disabled.
+	* config/i386/i386.h (TARGET_SWITCHES): Disabling sse also disables
+	later sse generations.  Disabling mmx also disables 3dnow.
+
+2004-12-22  Daniel Berlin  <dberlin@dberlin.org>
+	
+	* tree-inline.c (struct inline_data): Remove inlined_fns.
+	(expand_call_inline): Remove dead code setting
+	inlined_fns.
+	(optimize_inline_calls): Remove dead code setting DECL_INLINED_FNS.
+	* tree.h (struct tree_decl): Remove inlined_fns.
+
 2004-12-22  Roger Sayle  <roger@eyesopen.com>
 
 	* tree-browser.c: Remove obsolete #ifdef HOST_EBCDIC code.

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