This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
A recent patch increased GCC's memory consumption!
- From: gcctest at suse dot de
- To: jh at suse dot cz, gcc-regression at gcc dot gnu dot org
- Date: Thu, 09 Feb 2006 17:30:21 +0000
- Subject: A recent patch increased GCC's memory consumption!
Hi,
I am a friendly script caring about memory consumption in GCC. Please
contact jh@suse.cz if something is going wrong.
Comparing memory consumption on compilation of combine.i, insn-attrtab.i,
and generate-3.4.ii I got:
comparing combine.c compilation at -O0 level:
Overall memory needed: 25320k
Peak memory use before GGC: 9566k
Peak memory use after GGC: 8914k
Maximum of released memory in single GGC run: 2649k
Garbage: 40057k
Leak: 6740k
Overhead: 5738k
GGC runs: 313
comparing combine.c compilation at -O1 level:
Overall memory needed: 26900k
Peak memory use before GGC: 17435k
Peak memory use after GGC: 17256k
Maximum of released memory in single GGC run: 2308k
Garbage: 62424k
Leak: 6890k
Overhead: 7487k
GGC runs: 392
comparing combine.c compilation at -O2 level:
Overall memory needed: 26900k
Peak memory use before GGC: 17438k
Peak memory use after GGC: 17256k
Maximum of released memory in single GGC run: 2399k
Garbage: 82367k -> 82367k
Leak: 6976k
Overhead: 10226k
GGC runs: 461
comparing combine.c compilation at -O3 level:
Overall memory needed: 26900k
Peak memory use before GGC: 18453k
Peak memory use after GGC: 17993k
Maximum of released memory in single GGC run: 3495k
Garbage: 113575k -> 113575k
Leak: 7053k
Overhead: 13950k
GGC runs: 518
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 80948k
Peak memory use before GGC: 69508k
Peak memory use after GGC: 45045k
Maximum of released memory in single GGC run: 36220k
Garbage: 146686k
Leak: 9908k
Overhead: 19751k
GGC runs: 247
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 109264k
Peak memory use before GGC: 92085k
Peak memory use after GGC: 81244k
Maximum of released memory in single GGC run: 32383k
Garbage: 296341k
Leak: 10076k
Overhead: 36186k
GGC runs: 246
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 110872k
Peak memory use before GGC: 93803k
Peak memory use after GGC: 81343k
Maximum of released memory in single GGC run: 31927k
Garbage: 343615k
Leak: 10059k
Overhead: 44783k
GGC runs: 275
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 110840k
Peak memory use before GGC: 93833k
Peak memory use after GGC: 81373k
Maximum of released memory in single GGC run: 32267k
Garbage: 344265k
Leak: 10063k
Overhead: 44982k
GGC runs: 280
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 118424k -> 118252k
Peak memory use before GGC: 95198k -> 95027k
Peak memory use after GGC: 94250k -> 94080k
Maximum of released memory in single GGC run: 20356k -> 20299k
Garbage: 223714k -> 223447k
Leak: 49472k -> 49470k
Overhead: 37113k -> 37085k
GGC runs: 369
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory needed: 108528k -> 108460k
Peak memory use before GGC: 95331k -> 95143k
Peak memory use after GGC: 93251k -> 93151k
Maximum of released memory in single GGC run: 20233k -> 20158k
Garbage: 564802k -> 563714k
Leak: 52294k -> 52249k
Overhead: 63643k -> 63585k
GGC runs: 531 -> 533
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory needed: 108532k -> 108476k
Peak memory use before GGC: 95331k -> 95143k
Peak memory use after GGC: 93252k -> 93152k
Maximum of released memory in single GGC run: 20232k -> 20158k
Garbage: 687276k -> 687208k
Leak: 53428k -> 53378k
Overhead: 76835k -> 76820k
GGC runs: 617 -> 615
comparing Gerald's testcase PR8361 compilation at -O3 level:
Peak amount of GGC memory still allocated after garbage collectin increased from 94327k to 94579k, overall 0.27%
Overall memory needed: 114208k -> 110792k
Peak memory use before GGC: 96797k -> 96537k
Peak memory use after GGC: 94327k -> 94579k
Maximum of released memory in single GGC run: 20729k -> 20582k
Garbage: 753507k -> 753379k
Leak: 54360k -> 54326k
Overhead: 81753k -> 81589k
GGC runs: 629
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2006-02-09 05:53:25.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2006-02-09 16:21:02.000000000 +0000
@@ -1,3 +1,62 @@
+2006-02-09 Richard Earnshaw <richard.earnshaw@arm.com>
+
+ * arm.md (tlobits_cbranch): New pattern.
+ * arm.h (arm_select_cc_mode): For thumb, only return CC_Nmode if
+ testing a single bit.
+
+2006-02-09 Andrew Pinski <pinskia@physics.uc.edu>
+
+ PR tree-opt/26179
+ * tree-ssa-pre.c (create_component_ref_by_pieces):
+ Handle RETURN_DECL like VAR_DECL.
+
+2006-02-09 Andrew Pinski <pinskia@physics.uc.edu>
+
+ PR middle-end/26134
+ * fold-const.c (fold_indirect_ref_1): Fold
+ "*(foo *)&complexfoo" to "__real__ complexfoo"
+ and "((foo*)&complexfoo)[1]" to "__imag__ complexfoo".
+
+2006-02-09 Andrew Pinski <pinskia@physics.uc.edu>
+
+ * tree-flow-inline.h (var_can_have_subvars):
+ Volatile variables should not have subvariables.
+
+2006-02-09 Diego Novillo <dnovillo@redhat.com>
+
+ PR 26180
+ * tree-vrp.c (vrp_int_const_binop): Detect overflow when
+ multiplying unsigned values.
+ Tidy comments.
+
+2006-02-09 Eric Botcazou <ebotcazou@libertysurf.fr>
+
+ * config/sparc/sparc.c (tls_call_delay): Fix oversight.
+
+2006-02-08 Jason Merrill <jason@redhat.com>
+
+ PR c++/25979
+ * tree.def: Elaborate on difference from MODIFY_EXPR.
+ * doc/c-tree.texi (INIT_EXPR): Likewise.
+ * gimplify.c (internal_get_tmp_var): Use INIT_EXPR.
+ (gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
+ (gimplify_target_expr): Likewise.
+ (gimplify_cond_expr): Remove target handling.
+ (gimplify_modify_expr): Don't clobber INIT_EXPR code here.
+ (gimplify_expr): Clobber it here.
+ (gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
+ Do return slot optimization if we have an INIT_EXPR.
+
+ PR tree-opt/24365
+ * tree-inline.c (declare_return_variable): Also clear
+ DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.
+
+ PR c++/16405
+ * gimplify.c (gimplify_modify_expr_rhs): Re-enable *& handling.
+
+ PR middle-end/22439
+ * gimplify.c (gimplify_one_sizepos): Fix typo.
+
2006-02-08 Jeff Law <law@redhat.com>
PR tree-optimization/21417
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2006-02-08 19:27:04.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2006-02-09 16:21:02.000000000 +0000
@@ -1,3 +1,10 @@
+2006-02-08 Jason Merrill <jason@redhat.com>
+
+ PR c++/25979
+ * cp-gimplify.c (cp_gimplify_expr): Don't call
+ cp_gimplify_init_expr for MODIFY_EXPRs.
+ * typeck2.c (split_nonconstant_init_1): Use INIT_EXPR.
+
2006-02-08 Volker Reichelt <reichelt@igpm.rwth-aachen.de>
PR c++/26071
The results can be reproduced by building a 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.
Your testing script.