GCC memory consumption increased by recent patch!
gcctest@suse.de
gcctest@suse.de
Wed May 11 20:46: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: 24996k
Peak memory use before GGC: 9439k
Peak memory use after GGC: 8752k
Maximum of released memory in single GGC run: 2797k
Garbage: 42285k -> 42285k
Leak: 6487k -> 6486k
Overhead: 5875k -> 5873k
GGC runs: 326
comparing combine.c compilation at -O1 level:
Overall memory needed: 27396k -> 27400k
Peak memory use before GGC: 8890k
Peak memory use after GGC: 8548k
Maximum of released memory in single GGC run: 2235k
Garbage: 63560k -> 63521k
Leak: 6847k -> 6846k
Overhead: 7729k -> 7725k
GGC runs: 524 -> 523
comparing combine.c compilation at -O2 level:
Overall memory needed: 19952k
Peak memory use before GGC: 12764k
Peak memory use after GGC: 12634k
Maximum of released memory in single GGC run: 2625k
Garbage: 88642k -> 88610k
Leak: 6653k -> 6653k
Overhead: 11082k -> 11078k
GGC runs: 539
comparing combine.c compilation at -O3 level:
Amount of memory still referenced at the end of compilation increased from 7102k to 7117k, overall 0.22%
Overall memory needed: 22788k -> 22800k
Peak memory use before GGC: 15325k
Peak memory use after GGC: 12917k -> 12919k
Maximum of released memory in single GGC run: 3092k
Garbage: 123445k -> 123377k
Leak: 7102k -> 7117k
Overhead: 15293k -> 15286k
GGC runs: 611
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 85876k
Peak memory use before GGC: 74240k
Peak memory use after GGC: 45261k
Maximum of released memory in single GGC run: 38092k
Garbage: 154669k -> 154669k
Leak: 11186k -> 11186k
Overhead: 19889k -> 19888k
GGC runs: 268
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 103548k
Peak memory use before GGC: 81339k
Peak memory use after GGC: 66512k
Maximum of released memory in single GGC run: 35980k
Garbage: 308184k -> 308184k
Leak: 11470k -> 11469k
Overhead: 37961k -> 37960k
GGC runs: 386
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 140412k -> 140404k
Peak memory use before GGC: 107838k
Peak memory use after GGC: 82700k
Maximum of released memory in single GGC run: 35344k
Garbage: 404704k -> 404703k
Leak: 11434k -> 11433k
Overhead: 50829k -> 50828k
GGC runs: 336
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 140420k -> 140412k
Peak memory use before GGC: 107838k
Peak memory use after GGC: 82703k
Maximum of released memory in single GGC run: 35344k
Garbage: 405481k -> 405481k
Leak: 11454k -> 11454k
Overhead: 50951k -> 50951k
GGC runs: 343
comparing Gerald's testcase PR8361 compilation at -O0 level:
Peak amount of GGC memory allocated before garbage collecting increased from 87827k to 87992k, overall 0.19%
Peak amount of GGC memory still allocated after garbage collectin increased from 86409k to 86574k, overall 0.19%
Overall memory needed: 112460k -> 112632k
Peak memory use before GGC: 87827k -> 87992k
Peak memory use after GGC: 86409k -> 86574k
Maximum of released memory in single GGC run: 20839k -> 20913k
Garbage: 248055k -> 248298k
Leak: 53983k -> 53968k
Overhead: 43233k -> 43197k
GGC runs: 370
comparing Gerald's testcase PR8361 compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 86942k to 87096k, overall 0.18%
Peak amount of GGC memory still allocated after garbage collectin increased from 85413k to 85586k, overall 0.20%
Amount of produced GGC garbage increased from 567916k to 601744k, overall 5.96%
Amount of memory still referenced at the end of compilation increased from 57427k to 58076k, overall 1.13%
Overall memory needed: 95036k -> 95204k
Peak memory use before GGC: 86942k -> 87096k
Peak memory use after GGC: 85413k -> 85586k
Maximum of released memory in single GGC run: 20531k -> 20594k
Garbage: 567916k -> 601744k
Leak: 57427k -> 58076k
Overhead: 72998k -> 76822k
GGC runs: 611 -> 621
comparing Gerald's testcase PR8361 compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting increased from 86942k to 87097k, overall 0.18%
Peak amount of GGC memory still allocated after garbage collectin increased from 85413k to 85587k, overall 0.20%
Amount of produced GGC garbage increased from 662190k to 706509k, overall 6.69%
Amount of memory still referenced at the end of compilation increased from 58233k to 58949k, overall 1.23%
Overall memory needed: 95028k -> 96044k
Peak memory use before GGC: 86942k -> 87097k
Peak memory use after GGC: 85413k -> 85587k
Maximum of released memory in single GGC run: 20530k -> 20595k
Garbage: 662190k -> 706509k
Leak: 58233k -> 58949k
Overhead: 91381k -> 95586k
GGC runs: 703 -> 745
comparing Gerald's testcase PR8361 compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 87872k to 88036k, overall 0.19%
Peak amount of GGC memory still allocated after garbage collectin increased from 86704k to 86868k, overall 0.19%
Amount of produced GGC garbage increased from 682139k to 683176k, overall 0.15%
Overall memory needed: 96100k -> 96316k
Peak memory use before GGC: 87872k -> 88036k
Peak memory use after GGC: 86704k -> 86868k
Maximum of released memory in single GGC run: 20795k -> 20868k
Garbage: 682139k -> 683176k
Leak: 59010k -> 59064k
Overhead: 94161k -> 94430k
GGC runs: 706 -> 709
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-05-11 07:00:29.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-05-11 19:43:50.000000000 +0000
@@ -1,3 +1,157 @@
+2005-05-11 Richard Sandiford <rsandifo@redhat.com>
+
+ * config/mips/sr71k.md, config/mips/7000.md: Reformat.
+
+2005-05-11 Kazu Hirata <kazu@cs.umass.edu>
+
+ PR tree-optimizer/18472
+ * tree-if-conv.c (tree_if_convert_stmt,
+ if_convertible_modify_expr_p): Don't handle GOTO_EXPR.
+
+2005-05-11 Jan Hubicka <jh@suse.cz>
+
+ * Makefile.in (tree-eh.o: Kill gt-tree-eh.h dependency.
+ (GTFILES): add except.h.
+ * except.c (eh_status): Add throw_stmt_table.
+ (set_eh_throw_stmt_table, get_eh_throw_stmt_table): New functions.
+ * except.h (add_stmt_to_eh_region_fn, remove_stmt_from_eh_region_fn,
+ lookup_stmt_eh_region_fn): Declare.
+ (throw_stmt_node): New structure.
+ (set_eh_throw_stmt_table, get_eh_throw_stmt_table): New.
+ * gengtype.c (open_base_files): Add except.h to inlines.
+ * tree-eh.c (throw_stmt_node): Kill.
+ (record_stmt_eh_region): Update.
+ (add_stmt_to_eh_region_fn): Break out from ...
+ (add_stmt_to_eh_region): ... here.
+ (remove_stmt_from_eh_region_fn): Break out from ...
+ (remove_stmt_from_eh_region): ... here.
+ (lookup_stmt_eh_region_fn): Break out from ...
+ (lookup_stmt_eh_region): ... here.
+ (honor_protect_cleanup_actions): Use build_resx.
+ (lower_try_finally_onedest): Likewise.
+ (lower_try_finally_copy): Likewise.
+ (lower_try_finally_switch): Likewise.
+ (lower_eh_constructs): Update eh table construction.
+ * tree.c (build_resx): New.
+ * tree.h (build_resx): Declare.
+
+2005-05-11 H.J. Lu <hongjiu.lu@intel.com>
+
+ * libgcov.c (gcov_exit): Set prefix_length to 0 if no relocation
+ is needed.
+
+2005-05-11 Kazu Hirata <kazu@cs.umass.edu>
+
+ * fold-const.c, libgcov.c: Fix comment typos.
+
+ * tree-ssa-forwprop.c (forward_propagate_into_cond_1): Remove
+ redundant code.
+
+2005-05-11 Daniel Jacobowitz <dan@codesourcery.com>
+
+ * config/arm/linux-elf.h (SUBTARGET_FRAME_POINTER_REQUIRED): Define.
+ * config/arm/arm.h (SUBTARGET_FRAME_POINTER_REQUIRED): Provide
+ default definition.
+ (FRAME_POINTER_REQUIRED): Use SUBTARGET_FRAME_POINTER_REQUIRED.
+
+2005-05-11 Nathan Sidwell <nathan@codesourcery.com>
+
+ PR bootstrap/21481
+ * crtstuff.c: Include auto-host.h again, for now.
+
+2005-05-11 Richard Sandiford <rsandifo@redhat.com>
+
+ * config/mips/24k.md: Remove trailing whitespace.
+
+2005-05-11 David Ung <davidu@mips.com>
+
+ * config/mips/mips.md (type): Add imul3.
+ (length, hazard, may_clobber_hilo): Check for imul3.
+ (mulsi3_mult3, muldi3_mult3, *muls, <su>mulsi3_highpart_mulhi_internal)
+ (*<su>mulsi3_highpart_neg_mulhi_internal): Set attr to imul3.
+ * config/mips/24k.md (r24k_int_mul3): Enable this reservation
+ for a 3 operand mul and its bypasses.
+ * config/mips/3000.md (r3k_imul): Add imul3 to reservations.
+ * config/mips/4000.md (r4k_imul): Likewise.
+ * config/mips/4100.md (r4100_imul_si, r4100_imul_di): Likewise.
+ * config/mips/4130.md (vr4130_class, vr4130_mulsi)
+ (vr4130_muldi): Likewise.
+ * config/mips/4300.md (r4300_imul_si, r4300_imul_di): Likewise.
+ * config/mips/4600.md (r4600_imul, r4650_imul): Likewise.
+ * config/mips/5000.md (r5k_imul_si, r5k_imul_di): Likewise.
+ * config/mips/5400.md (ir_vr54_imul_si, ir_vr54_imul_di)
+ (ir_vr54_imadd_si): Likewise.
+ * config/mips/5500.md (ir_vr55_imul_si, ir_vr55_imul_di): Likewise.
+ * config/mips/7000.md (rm7_impy_si_mult, rm7_impy_si_mul)
+ (rm7_impy_di): Likewise.
+ * config/mips/9000.md (rm9k_mulsi, rm9k_muldi): Likewise.
+ * config/mips/generic.md (generic_imul): Likewise.
+ * config/mips/sb1.md (ir_sb1_mulsi, ir_sb1_muldi): Likewise.
+ * config/mips/sr71k.md (ir_sr70_imul_si, ir_sr70_imul_di): Likewise.
+
+2005-05-11 J"orn Rennecke <joern.rennecke@st.com>
+
+ PR middle-end/20371:
+ * tree.h (record_layout_info_s): New member prev_packed.
+ * stor-layout.c (update_alignment_for_field): Fix comment about
+ KNOWN_ALIGN. For MS bitfields, if we start a new run, make sure
+ we start it properly aligned.
+ (place_field): At the beginning of a record, pass 0 as KNOWN_ALIGN
+ to update_alignment_for_field, and recompute it afterwards using
+ the alignment of the record.
+ When a packed bitfield precedes an MS bitfield, don't add padding
+ at the end of the packed bitfield on behalf of the base type of
+ the packed bit field.
+ Don't adjust rli->bitpos at the end
+ of an MS bitfield run if we already adjusted bitpos/offset for an
+ alignment as large or larger than the bitfield type size.
+ Take possible record alignment > BIGGEST_ALIGNMENT into account
+ when calculating actual_align.
+ Only put packed buit fields into rli->prev_field if they end up
+ suitably aligned.
+ Also set rli->remaining_in_alignment when we re-set rli->prev_field.
+ Update rli->remaining_in_alignment when we have already started a
+ run of bit fields and we process a packed bit field.
+
+2005-05-11 Sebastian Pop <pop@cri.ensmp.fr>
+
+ * tree-data-ref.c (find_data_references_in_loop): Give up when
+ the body of the loop contains a CALL_EXPR or an ASM_EXPR: they
+ may embed arbitrary side effects.
+ Remove the assumption that GIMPLE form contains a single array
+ access per statement.
+ When the statement contains virtual operands, fail if it is not
+ a MODIFY_EXPR or a CALL_EXPR.
+ Return after the dont know node is inserted.
+
+2005-05-11 Richard Earnshaw <richard.earnshaw@arm.com>
+
+ * arm.md (negsf2, negdf2): Permit these expands when compiling for VFP.
+
+2005-05-11 Richard Guenther <rguenth@gcc.gnu.org>
+
+ PR middle-end/19807
+ PR tree-optimization/19639
+ * fold-const.c (try_move_mult_to_index): Handle INTEGER_CST
+ and generic summands for char* as s * delta, too, folding &a[i]
+ CODE x to &a[i CODE x/s]. Use tree_int_cst_equal
+ for comparison of steps. Convert types for index addition.
+ (fold_binary): Adjust the callers to always dispatch to
+ try_move_mult_to_index.
+ * tree-ssa-propagate.c (set_rhs): Avoid setting rhs to
+ expr with non-gimple ARRAY_REF offset.
+
+2005-05-11 Richard Guenther <rguenth@gcc.gnu.org>
+
+ * fold-const.c (fold_indirect_ref_1): Avoid removing
+ NOP_EXPRs with type qualifiers like const.
+
+2005-05-11 Richard Henderson <rth@redhat.com>
+
+ PR c/21502
+ * c-decl.c (finish_decl): Propagate the completed array type of
+ a global variable into the binding.
+
2005-05-10 Matt Kraai <kraai@ftbfs.org>
* Makefile.in (gtype-desc.o, build/genautomata.o)
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