This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
A recent patch decreased 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: Sat, 08 Apr 2006 00:31:32 +0000
- Subject: A recent patch decreased 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: 25100k
Peak memory use before GGC: 9541k
Peak memory use after GGC: 8897k
Maximum of released memory in single GGC run: 2636k
Garbage: 39800k
Leak: 6735k
Overhead: 5657k
GGC runs: 314
comparing combine.c compilation at -O1 level:
Overall memory needed: 26892k
Peak memory use before GGC: 17430k
Peak memory use after GGC: 17251k
Maximum of released memory in single GGC run: 2302k
Garbage: 60977k
Leak: 6875k
Overhead: 7145k
GGC runs: 384
comparing combine.c compilation at -O2 level:
Overall memory needed: 26892k
Peak memory use before GGC: 17435k
Peak memory use after GGC: 17251k
Maximum of released memory in single GGC run: 2397k
Garbage: 84971k
Leak: 6992k
Overhead: 9831k
GGC runs: 450
comparing combine.c compilation at -O3 level:
Overall memory needed: 25992k
Peak memory use before GGC: 18548k
Peak memory use after GGC: 17843k
Maximum of released memory in single GGC run: 3544k
Garbage: 115911k
Leak: 7083k
Overhead: 13361k
GGC runs: 507
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 80372k
Peak memory use before GGC: 69292k
Peak memory use after GGC: 44790k
Maximum of released memory in single GGC run: 36009k
Garbage: 144206k
Leak: 10127k
Overhead: 19011k
GGC runs: 244
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 105464k
Peak memory use before GGC: 85351k
Peak memory use after GGC: 79199k
Maximum of released memory in single GGC run: 32294k
Garbage: 288186k
Leak: 10068k
Overhead: 33735k
GGC runs: 240
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 107532k
Peak memory use before GGC: 89783k
Peak memory use after GGC: 81656k
Maximum of released memory in single GGC run: 30744k
Garbage: 336898k
Leak: 10050k
Overhead: 41375k
GGC runs: 266
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 107636k
Peak memory use before GGC: 89809k
Peak memory use after GGC: 81683k
Maximum of released memory in single GGC run: 31076k
Garbage: 337514k
Leak: 10054k
Overhead: 41570k
GGC runs: 270
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 118260k
Peak memory use before GGC: 95027k
Peak memory use after GGC: 94083k
Maximum of released memory in single GGC run: 20342k
Garbage: 222873k
Leak: 49535k
Overhead: 37086k
GGC runs: 368
comparing Gerald's testcase PR8361 compilation at -O1 level:
Ovarall memory allocated via mmap and sbrk decreased from 144940k to 115852k, overall -25.11%
Peak amount of GGC memory allocated before garbage collecting run decreased from 132081k to 97678k, overall -35.22%
Overall memory needed: 144940k -> 115852k
Peak memory use before GGC: 132081k -> 97678k
Peak memory use after GGC: 97084k -> 96698k
Maximum of released memory in single GGC run: 34997k -> 18987k
Garbage: 471302k -> 471297k
Leak: 52822k
Overhead: 52713k -> 52713k
GGC runs: 474 -> 515
comparing Gerald's testcase PR8361 compilation at -O2 level:
Ovarall memory allocated via mmap and sbrk decreased from 144940k to 115856k, overall -25.10%
Peak amount of GGC memory allocated before garbage collecting run decreased from 132081k to 97678k, overall -35.22%
Overall memory needed: 144940k -> 115856k
Peak memory use before GGC: 132081k -> 97678k
Peak memory use after GGC: 97085k -> 96699k
Maximum of released memory in single GGC run: 34996k -> 18987k
Garbage: 559139k -> 559146k
Leak: 53715k -> 53716k
Overhead: 61360k -> 61364k
GGC runs: 556 -> 597
comparing Gerald's testcase PR8361 compilation at -O3 level:
Ovarall memory allocated via mmap and sbrk decreased from 147372k to 117128k, overall -25.82%
Peak amount of GGC memory allocated before garbage collecting run decreased from 134525k to 98973k, overall -35.92%
Overall memory needed: 147372k -> 117128k
Peak memory use before GGC: 134525k -> 98973k
Peak memory use after GGC: 98387k -> 97993k
Maximum of released memory in single GGC run: 36138k -> 19240k
Garbage: 580111k -> 580124k
Leak: 54074k -> 54072k
Overhead: 62473k -> 62473k
GGC runs: 563 -> 605
Head of the ChangeLog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2006-04-07 12:28:48.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2006-04-07 23:15:30.000000000 +0000
@@ -1,3 +1,32 @@
+2006-04-07 DJ Delorie <dj@redhat.com>
+
+ * config/m32c/m32c.c (m32c_function_arg): Structures are always
+ passed on the stack.
+ (m32c_init_cumulative_args): When a function returns a structure,
+ always pass the pointer to that return area on the stack.
+ (m32c_function_arg_advance): Don't increment the parameter number
+ if we're processing the returned structure pointer.
+ (pushm_info): Reverse order of registers.
+
+2006-04-07 Sebastian Pop <pop@cri.ensmp.fr>
+
+ * tree-ssa-loop-niter.c (inverse, number_of_iterations_ne,
+ assert_no_overflow_lt, assert_loop_rolls_lt, number_of_iterations_lt,
+ number_of_iterations_le, number_of_iterations_cond, find_loop_niter,
+ estimate_numbers_of_iterations_loop): Use build_int_cst instead of
+ build_int_cst_type.
+ * tree-chrec.c (chrec_fold_multiply_poly_poly,
+ chrec_fold_multiply): Same.
+ * tree-ssa-loop-ivopts.c (strip_offset_1, force_expr_to_var_cost,
+ force_expr_to_var_cost): Same.
+ * tree-mudflap.c (mf_xform_derefs_1): Same.
+ * tree-ssa-loop-prefetch.c (idx_analyze_ref): Same.
+
+2006-04-07 David Edelsohn <edelsohn@gnu.org>
+
+ * config/rs6000/rs6000.c (rs6000_rtx_costs) <CONST_DOUBLE>: Do not
+ treat CONST_DOUBLE as INTVAL. and64_2_operands require an extra
+ insn.
2006-04-07 Jan Hubicka <jh@suse.cz>
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.