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 decreased 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: 24649k -> 24645k
    Peak memory use before GGC: 9351k
    Peak memory use after GGC: 8665k
    Maximum of released memory in single GGC run: 2864k
    Garbage: 41665k
    Leak: 6387k
    Overhead: 5772k
    GGC runs: 328

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25485k -> 25489k
    Peak memory use before GGC: 9224k
    Peak memory use after GGC: 8733k
    Maximum of released memory in single GGC run: 2027k
    Garbage: 61170k
    Leak: 6749k
    Overhead: 9978k
    GGC runs: 503

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29549k
    Peak memory use before GGC: 12663k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 2597k
    Garbage: 79387k
    Leak: 6585k
    Overhead: 14118k
    GGC runs: 516

comparing combine.c compilation at -O3 level:
    Overall memory needed: 20228k
    Peak memory use before GGC: 12795k
    Peak memory use after GGC: 12537k
    Maximum of released memory in single GGC run: 3406k
    Garbage: 107335k
    Leak: 7110k
    Overhead: 18947k
    GGC runs: 582

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114136k
    Peak memory use before GGC: 74739k
    Peak memory use after GGC: 45485k
    Maximum of released memory in single GGC run: 39340k
    Garbage: 152660k
    Leak: 10976k
    Overhead: 19969k
    GGC runs: 273

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 124276k -> 124368k
    Peak memory use before GGC: 78748k
    Peak memory use after GGC: 70095k
    Maximum of released memory in single GGC run: 40779k
    Garbage: 366122k
    Leak: 11353k
    Overhead: 69302k
    GGC runs: 396

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 149040k -> 147408k
    Peak memory use before GGC: 98349k
    Peak memory use after GGC: 83466k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 480607k
    Leak: 11234k
    Overhead: 84551k
    GGC runs: 341

comparing insn-attrtab.c compilation at -O3 level:
  Ovarall memory allocated via mmap and sbrk decreased from 147392k to 137904k, overall -6.88%
    Overall memory needed: 147392k -> 137904k
    Peak memory use before GGC: 98351k
    Peak memory use after GGC: 83467k
    Maximum of released memory in single GGC run: 39385k
    Garbage: 481652k
    Leak: 11273k
    Overhead: 84702k
    GGC runs: 347

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 111096k
    Peak memory use before GGC: 86885k
    Peak memory use after GGC: 85935k
    Maximum of released memory in single GGC run: 19282k
    Garbage: 245826k
    Leak: 55495k
    Overhead: 43290k
    GGC runs: 367

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 103701k
    Peak memory use before GGC: 85967k
    Peak memory use after GGC: 84933k
    Maximum of released memory in single GGC run: 18946k
    Garbage: 444943k -> 445006k
    Leak: 56775k
    Overhead: 65509k -> 65510k
    GGC runs: 526

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 104725k
    Peak memory use before GGC: 85967k
    Peak memory use after GGC: 84933k
    Maximum of released memory in single GGC run: 18945k
    Garbage: 488034k -> 488017k
    Leak: 57364k -> 57372k
    Overhead: 75261k -> 75261k
    GGC runs: 584

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 112441k
    Peak memory use before GGC: 92707k
    Peak memory use after GGC: 86227k
    Maximum of released memory in single GGC run: 19713k
    Garbage: 503688k -> 503725k
    Leak: 57531k -> 57523k
    Overhead: 76947k -> 76950k
    GGC runs: 570

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-02-07 05:36:58.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-02-07 10:04:34.000000000 +0000
@@ -1,3 +1,40 @@
+2005-02-07  Richard Sandiford  <rsandifo@redhat.com>
+
+	PR bootstrap/19796
+	Revert:
+	2005-01-26  Richard Sandiford  <rsandifo@redhat.com>
+	* config/mips/iris6.h (ENDFILE_SPEC): Don't link in irix-csr.o if
+	either -ffast-math or -funsafe-math-optimizations is in use.
+
+	2005-01-24  Richard Sandiford  <rsandifo@redhat.com>
+	* config/mips/irix-csr.c: New file.
+	* config/mips/t-iris6 (irix-csr.o): New rule to build it.
+	(EXTRA_MULTILIB_PARTS): Add irix-csr.o.
+	* config/mips/iris6.h (ENDFILE_SPEC): Include it in n32 and n64
+	executables.
+
+2005-02-07  Alexandre Oliva  <aoliva@redhat.com>
+
+	* config/mn10300/linux.h (LIB_SPEC, STARTFILE_SPEC): Remove
+	redundant, incorrect definitions.
+
+	* config/frv/frv.md ("tls_indirect_call"): Turn into libcall-like
+	expand.
+	("*tls_indirect_call"): New, reference hard regs directly.
+	* config/frv/frv.c (gen_inlined_tls_plt): Adjust.
+
+2005-02-07  Ralf Corsepius  <ralf.corsepius@rtems.org>
+
+	* config/arm/rtems-elf.h (SUBTARGET_EXTRA_ASM_SPEC): 
+	Let !-mhard-float !-msoft-float imply -mfpu=softfpa.
+
+2005-02-06  Roger Sayle  <roger@eyesopen.com>
+
+	PR rtl-optimization/19800
+	* simplify_rtx.c (simplify_relational_operaration_1): Explicitly
+	call gen_lowpart_common and gen_lowpart_SUBREG instead of calling
+	gen_lowpart.
+
 2005-02-07  Ralf Corsepius  <ralf.corsepius@rtems.org>
 
 	* config/m68k/t-rtems (MULTILIB_MATCHES): Let m528x match m5200.

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]