This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
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: Thu, 10 Feb 2005 00:44:49 +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:
Amount of memory still referenced at the end of compilation increased from 6387k to 6407k, overall 0.30%
Overall memory needed: 24653k
Peak memory use before GGC: 9351k -> 9354k
Peak memory use after GGC: 8665k -> 8668k
Maximum of released memory in single GGC run: 2864k
Garbage: 41665k -> 41652k
Leak: 6387k -> 6407k
Overhead: 5772k -> 5772k
GGC runs: 328
comparing combine.c compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 25493k to 25541k, overall 0.19%
Overall memory needed: 25493k -> 25541k
Peak memory use before GGC: 9224k -> 9227k
Peak memory use after GGC: 8733k -> 8737k
Maximum of released memory in single GGC run: 2027k
Garbage: 61170k -> 61177k
Leak: 6749k -> 6752k
Overhead: 9978k -> 9977k
GGC runs: 503 -> 502
comparing combine.c compilation at -O2 level:
Overall memory needed: 29553k -> 29561k
Peak memory use before GGC: 12663k -> 12666k
Peak memory use after GGC: 12537k -> 12540k
Maximum of released memory in single GGC run: 2597k -> 2596k
Garbage: 79387k -> 79389k
Leak: 6585k -> 6589k
Overhead: 14118k -> 14119k
GGC runs: 516
comparing combine.c compilation at -O3 level:
Overall memory needed: 20228k -> 20208k
Peak memory use before GGC: 12795k -> 12798k
Peak memory use after GGC: 12537k -> 12540k
Maximum of released memory in single GGC run: 3406k
Garbage: 107335k -> 107338k
Leak: 7110k -> 7113k
Overhead: 18947k -> 18947k
GGC runs: 582 -> 583
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 114136k -> 114132k
Peak memory use before GGC: 74739k -> 74742k
Peak memory use after GGC: 45485k -> 45488k
Maximum of released memory in single GGC run: 39340k
Garbage: 152660k -> 152663k
Leak: 10976k -> 10979k
Overhead: 19969k -> 19969k
GGC runs: 273 -> 274
comparing insn-attrtab.c compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 123952k to 124652k, overall 0.56%
Overall memory needed: 123952k -> 124652k
Peak memory use before GGC: 78748k -> 78751k
Peak memory use after GGC: 70095k -> 70098k
Maximum of released memory in single GGC run: 40779k
Garbage: 366122k -> 366121k
Leak: 11353k -> 11356k
Overhead: 69302k -> 69302k
GGC runs: 396
comparing insn-attrtab.c compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 147408k to 149036k, overall 1.10%
Amount of memory still referenced at the end of compilation increased from 11234k to 11245k, overall 0.10%
Overall memory needed: 147408k -> 149036k
Peak memory use before GGC: 98349k -> 98356k
Peak memory use after GGC: 83466k -> 83472k
Maximum of released memory in single GGC run: 39384k -> 39385k
Garbage: 480607k -> 480593k
Leak: 11234k -> 11245k
Overhead: 84551k -> 84552k
GGC runs: 341
comparing insn-attrtab.c compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 137904k to 149052k, overall 8.08%
Amount of memory still referenced at the end of compilation increased from 11273k to 11284k, overall 0.10%
Overall memory needed: 137904k -> 149052k
Peak memory use before GGC: 98351k -> 98358k
Peak memory use after GGC: 83467k -> 83474k
Maximum of released memory in single GGC run: 39385k -> 39384k
Garbage: 481652k -> 481638k
Leak: 11273k -> 11284k
Overhead: 84702k -> 84702k
GGC runs: 347
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 111048k
Peak memory use before GGC: 87148k -> 87151k
Peak memory use after GGC: 85887k -> 85890k
Maximum of released memory in single GGC run: 19511k
Garbage: 246087k -> 246107k
Leak: 55514k -> 55517k
Overhead: 43323k -> 43323k
GGC runs: 366
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory needed: 103893k -> 103901k
Peak memory use before GGC: 86006k -> 86009k
Peak memory use after GGC: 85105k -> 85108k
Maximum of released memory in single GGC run: 18951k
Garbage: 445014k -> 445031k
Leak: 56768k -> 56779k
Overhead: 65385k -> 65386k
GGC runs: 523
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory needed: 93848k -> 93860k
Peak memory use before GGC: 86006k -> 86009k
Peak memory use after GGC: 85106k -> 85109k
Maximum of released memory in single GGC run: 18950k
Garbage: 487963k -> 487975k
Leak: 57371k -> 57374k
Overhead: 75138k -> 75140k
GGC runs: 586
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory needed: 105989k -> 105985k
Peak memory use before GGC: 87142k -> 87146k
Peak memory use after GGC: 86185k -> 86188k
Maximum of released memory in single GGC run: 19399k -> 19400k
Garbage: 498087k -> 498091k
Leak: 57569k -> 57565k
Overhead: 76119k -> 76117k
GGC runs: 563
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-02-09 18:23:40.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-02-09 23:45:41.000000000 +0000
@@ -1,3 +1,47 @@
+2005-02-09 Roger Sayle <roger@eyesopen.com>
+
+ * fold-const.c (fold_strip_sign_ops): New function to simplify a
+ floating point expression ignoring the sign of the result.
+ (fold) <ABS_EXPR>: Use it to simplify fabs(x).
+ (fold) <MULT_EXPR>: Use it to simplify x*x.
+ * tree.h (fold_strip_sign_ops): Prototype here.
+ * builtins.c (fold_builtin_copysign): Take an additional FNDECL
+ argument. Use fold_strip_sign_ops to simplify the first argument.
+ (fold_builtin_pow): Use fold_strip_sign_ops to simplify the
+ first argument when the second argument is an even integer
+ constant, but only with -funsafe_math_optimizations.
+ (fold_builtin_1): Update call to fold_builtin_copysign.
+
+2005-02-09 Ian Lance Taylor <ian@airs.com>
+
+ PR middle-end/19583
+ * gimple-low.c (try_catch_may_fallthru): In EH_FILTER_EXPR case,
+ just check whether EH_FILTER_FAILURE falls through.
+
+2005-02-09 Andreas Krebbel <krebbel1@de.ibm.com>
+
+ * gcc/haifa-sched.c (schedule_block): Make queued sched group
+ insns return to ready list in the next turn.
+
+2005-02-09 Richard Guenther <rguenth@gcc.gnu.org>
+
+ PR middle-end/19402
+ * builtins.def: New __builtin_powi[lf].
+ * builtins.c (mathfn_built_in): Handle BUILT_IN_POWI.
+ (expand_builtin_powi): New function.
+ (expand_builtin): Dispatch to expand_builtin_powi.
+ * libgcc2.h: Add prototypes for __builtin_powi[lf].
+ * libgcc2.c: Add __builtin_powi[lf] implementation.
+ * mklibgcc.in: Add __builtin_powi[lf] to lib2funcs.
+ * optabs.h: Add powi_optab.
+ * optabs.c (init_optabs): Initialize powi_optab.
+ * doc/extend.texi: Document __builtin_powi[lf].
+
+2005-02-09 Dorit Naishlos <dorit@il.ibm.com>
+
+ * tree-vectorizer.c (vect_set_dump_settings): Check that dump_file
+ exists.
+
2005-02-09 Richard Guenther <rguenth@gcc.gnu.org>
PR middle-end/19854
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.