Some aspect of GCC memory consumption increased by recent patch
gcctest@suse.de
gcctest@suse.de
Tue Feb 1 13:17:00 GMT 2005
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: 24637k -> 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: 25497k -> 25501k
Peak memory use before GGC: 9228k
Peak memory use after GGC: 8733k
Maximum of released memory in single GGC run: 2027k
Garbage: 61218k
Leak: 6749k
Overhead: 9980k
GGC runs: 503
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 79173k to 79478k, overall 0.38%
Overall memory needed: 29541k -> 29545k
Peak memory use before GGC: 12663k
Peak memory use after GGC: 12537k
Maximum of released memory in single GGC run: 2550k -> 2596k
Garbage: 79173k -> 79478k
Leak: 6585k
Overhead: 14094k -> 14136k
GGC runs: 515 -> 516
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 106976k to 107420k, overall 0.42%
Overall memory needed: 20212k -> 20176k
Peak memory use before GGC: 12794k
Peak memory use after GGC: 12537k
Maximum of released memory in single GGC run: 3345k -> 3407k
Garbage: 106976k -> 107420k
Leak: 7098k -> 7074k
Overhead: 18885k -> 18944k
GGC runs: 581 -> 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: 125300k -> 124884k
Peak memory use before GGC: 78748k
Peak memory use after GGC: 70095k
Maximum of released memory in single GGC run: 40765k
Garbage: 367812k
Leak: 11353k
Overhead: 69563k
GGC runs: 399
comparing insn-attrtab.c compilation at -O2 level:
Amount of produced GGC garbage increased from 481106k to 482425k, overall 0.27%
Overall memory needed: 148992k -> 149040k
Peak memory use before GGC: 98349k
Peak memory use after GGC: 83466k
Maximum of released memory in single GGC run: 39290k -> 39253k
Garbage: 481106k -> 482425k
Leak: 11239k -> 11234k
Overhead: 84673k -> 84837k
GGC runs: 341 -> 342
comparing insn-attrtab.c compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 147352k to 149028k, overall 1.14%
Amount of produced GGC garbage increased from 482150k to 483475k, overall 0.27%
Overall memory needed: 147352k -> 149028k
Peak memory use before GGC: 98351k
Peak memory use after GGC: 83467k
Maximum of released memory in single GGC run: 39291k -> 39254k
Garbage: 482150k -> 483475k
Leak: 11277k -> 11273k
Overhead: 84822k -> 84987k
GGC runs: 347 -> 348
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory allocated via mmap and sbrk increased from 110792k to 111092k, overall 0.27%
Peak amount of GGC memory allocated before garbage collecting increased from 86594k to 86885k, overall 0.34%
Peak amount of GGC memory still allocated after garbage collectin increased from 85642k to 85935k, overall 0.34%
Amount of produced GGC garbage increased from 207460k to 245826k, overall 18.49%
Amount of memory still referenced at the end of compilation increased from 54069k to 55495k, overall 2.64%
Overall memory needed: 110792k -> 111092k
Peak memory use before GGC: 86594k -> 86885k
Peak memory use after GGC: 85642k -> 85935k
Maximum of released memory in single GGC run: 19192k -> 19282k
Garbage: 207460k -> 245826k
Leak: 54069k -> 55495k
Overhead: 36026k -> 43290k
GGC runs: 317 -> 367
comparing Gerald's testcase PR8361 compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 102265k to 103697k, overall 1.40%
Peak amount of GGC memory allocated before garbage collecting increased from 85625k to 85967k, overall 0.40%
Peak amount of GGC memory still allocated after garbage collectin increased from 84691k to 84933k, overall 0.29%
Amount of produced GGC garbage increased from 155717k to 445679k, overall 186.21%
Amount of memory still referenced at the end of compilation decreased from 70830k to 56775k, overall -24.76%
Overall memory needed: 102265k -> 103697k
Peak memory use before GGC: 85625k -> 85967k
Peak memory use after GGC: 84691k -> 84933k
Maximum of released memory in single GGC run: 18803k -> 18946k
Garbage: 155717k -> 445679k
Leak: 70830k -> 56775k
Overhead: 31643k -> 65545k
GGC runs: 256 -> 526
comparing Gerald's testcase PR8361 compilation at -O2 level:
Overall memory allocated via mmap and sbrk increased from 102261k to 104737k, overall 2.42%
Peak amount of GGC memory allocated before garbage collecting increased from 85625k to 85967k, overall 0.40%
Peak amount of GGC memory still allocated after garbage collectin increased from 84692k to 84933k, overall 0.28%
Amount of produced GGC garbage increased from 155764k to 488584k, overall 213.67%
Amount of memory still referenced at the end of compilation decreased from 70901k to 57371k, overall -23.58%
Overall memory needed: 102261k -> 104737k
Peak memory use before GGC: 85625k -> 85967k
Peak memory use after GGC: 84692k -> 84933k
Maximum of released memory in single GGC run: 18802k -> 18945k
Garbage: 155764k -> 488584k
Leak: 70901k -> 57371k
Overhead: 31661k -> 75281k
GGC runs: 256 -> 584
comparing Gerald's testcase PR8361 compilation at -O3 level:
Overall memory allocated via mmap and sbrk increased from 109901k to 112433k, overall 2.30%
Peak amount of GGC memory allocated before garbage collecting increased from 92289k to 92707k, overall 0.45%
Peak amount of GGC memory still allocated after garbage collectin increased from 85886k to 86227k, overall 0.40%
Amount of produced GGC garbage increased from 154891k to 504572k, overall 225.76%
Amount of memory still referenced at the end of compilation decreased from 72139k to 57528k, overall -25.40%
Overall memory needed: 109901k -> 112433k
Peak memory use before GGC: 92289k -> 92707k
Peak memory use after GGC: 85886k -> 86227k
Maximum of released memory in single GGC run: 19647k -> 19713k
Garbage: 154891k -> 504572k
Leak: 72139k -> 57528k
Overhead: 31584k -> 76988k
GGC runs: 255 -> 569
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-02-01 03:32:10.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-02-01 12:16:09.000000000 +0000
@@ -1,3 +1,52 @@
+2005-02-01 Steven Bosscher <stevenb@suse.de>
+
+ PR optimization/15242
+ * params.def (PARAM_MAX_GOTO_DUPLICATION_INSNS): New param.
+ * basic-block.h (duplicate_computed_gotos): Add prototype.
+ * bb-reorder.c (duplicate_computed_gotos): New function to
+ duplicate sufficiently small blocks ending in a computed jump.
+ * passes.c (rest_of_compilation): Call duplicate_computed_gotos
+ if not optimizing for size.
+ * cfgcleanup.c (try_crossjump_bb): If not optimizing for size,
+ never do tail merging for blocks ending in a computed jump.
+ * doc/invoke.texi: Document the max-goto-duplication-insns param.
+
+2005-02-01 Eric Botcazou <ebotcazou@libertysurf.fr>
+
+ Patch from Richard Sandiford <rsandifo@redhat.com>
+ * reload1.c (choose_reload_regs): Prevent the find_equiv_reg() code
+ from inheriting a subreg equivalence with a non-spill register.
+
+ * tree.h (DECL_FUNCTION_CODE): Document that it is overloaded.
+
+2005-02-01 Alexandre Oliva <aoliva@redhat.com>
+
+ * config/frv/frv.c (movcc_fp_destination_operand): New.
+ (gpr_or_memory_operand): Fix typo in comment.
+ (gpr_or_memory_operand_with_scratch): New.
+ * config/frv/frv.h (PREDICATE_CODES): Add the two new predicates.
+ * config/frv/frv.md (movcc_fp, movcc_fp_internal): Use
+ movcc_fp_destination_operand.
+ (reload_incc_fp): Use gpr_or_memory_operand_with_scratch.
+ Legitimize memory addresses using a scratch register.
+
+2005-01-31 Jeff Law <law@redhat.com>
+
+ * tree-into-ssa.c (mark_def_sites_global_data): Make KILLS
+ bitmap a sparse bitmap instead of a simple bitmap.
+ (mark_def_sites_initialize_block): Corresponding changes.
+ (ssa_mark_def_sites_initialize_block): Likewise.
+ (ssa_mark_phi_uses): Likewise.
+ (mark_def_site, ssa_mark_def_sites): Likewise.
+ (mark_def_site_blocks): Likewise.
+ (rewrite_ssa_into_ssa): Likewise.
+
+ * tree-ssa-dom.c (record_cond): Pass correct variable type
+ for last argument to htab_find_slot_with_hash.
+
+ * fold-const.c (fold, case CEIL_MOD_EXPR): Do not lose side
+ effects when optimizing 0 % X. Do not try to optimize X % 0.
+
2005-01-31 James E. Wilson <wilson@specifixinc.com>
* config/ia64/itanium1.md (1_scall bypass): Change 2_mmalua to
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2005-02-01 03:32:20.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2005-02-01 12:16:17.000000000 +0000
@@ -1,5 +1,23 @@
2005-01-31 Mark Mitchell <mark@codesourcery.com>
+ * parser.c (cp_parser_primary_expression): Don't complain about
+ floating-point literals in integral constant expressions when
+ !pedantic.
+
+2005-02-01 Alexandre Oliva <aoliva@redhat.com>
+
+ * parser.c (cp_parser_template_id): Revert comment patch too.
+
+ PR c++/18757
+ PR c++/19366
+ PR c++/19499
+ * parser.c (cp_parser_template_id): Revert 2004-12-09's patch.
+ Issue an error when creating the template id.
+ * pt.c (fn_type_unification): Return early if the explicit
+ template arg list is an error_mark_node.
+
+2005-01-31 Mark Mitchell <mark@codesourcery.com>
+
* decl.c (build_enumerator): Do not issue duplicate error messages
about invalid enumeration constants.
* parser.c (cp_parser_non_integral_constant_expression): Always
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