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: Sat, 07 May 2005 02:26:29 +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:
Overall memory needed: 24996k
Peak memory use before GGC: 9438k
Peak memory use after GGC: 8751k
Maximum of released memory in single GGC run: 2797k
Garbage: 42333k
Leak: 6471k
Overhead: 5873k
GGC runs: 327
comparing combine.c compilation at -O1 level:
Overall memory needed: 27184k -> 27156k
Peak memory use before GGC: 8818k
Peak memory use after GGC: 8552k
Maximum of released memory in single GGC run: 2171k
Garbage: 60697k -> 60728k
Leak: 6838k
Overhead: 7617k -> 7619k
GGC runs: 501 -> 500
comparing combine.c compilation at -O2 level:
Overall memory needed: 19948k
Peak memory use before GGC: 12763k
Peak memory use after GGC: 12633k
Maximum of released memory in single GGC run: 2618k
Garbage: 85965k -> 86031k
Leak: 6656k
Overhead: 11008k -> 11016k
GGC runs: 524
comparing combine.c compilation at -O3 level:
Amount of produced GGC garbage increased from 119151k to 119394k, overall 0.20%
Overall memory needed: 23168k -> 23144k
Peak memory use before GGC: 14755k -> 14731k
Peak memory use after GGC: 12984k -> 12960k
Maximum of released memory in single GGC run: 3069k
Garbage: 119151k -> 119394k
Leak: 7102k -> 7103k
Overhead: 15185k -> 15203k
GGC runs: 590 -> 591
comparing insn-attrtab.c compilation at -O0 level:
Overall memory needed: 86000k -> 85868k
Peak memory use before GGC: 74239k
Peak memory use after GGC: 45259k
Maximum of released memory in single GGC run: 38092k
Garbage: 154683k
Leak: 11186k
Overhead: 19888k
GGC runs: 268
comparing insn-attrtab.c compilation at -O1 level:
Overall memory needed: 99268k -> 99364k
Peak memory use before GGC: 72837k
Peak memory use after GGC: 64735k
Maximum of released memory in single GGC run: 37096k
Garbage: 309794k -> 309793k
Leak: 11478k
Overhead: 38014k -> 38013k
GGC runs: 375
comparing insn-attrtab.c compilation at -O2 level:
Overall memory needed: 142448k -> 142428k
Peak memory use before GGC: 116906k -> 116905k
Peak memory use after GGC: 88272k
Maximum of released memory in single GGC run: 35225k
Garbage: 426746k -> 426751k
Leak: 11300k
Overhead: 52896k -> 52895k
GGC runs: 331
comparing insn-attrtab.c compilation at -O3 level:
Overall memory needed: 142456k -> 142452k
Peak memory use before GGC: 116908k -> 116907k
Peak memory use after GGC: 88274k
Maximum of released memory in single GGC run: 35225k
Garbage: 427496k -> 427504k
Leak: 11330k
Overhead: 53019k -> 53019k
GGC runs: 336 -> 337
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 112444k -> 112436k
Peak memory use before GGC: 87853k -> 87845k
Peak memory use after GGC: 86397k -> 86389k
Maximum of released memory in single GGC run: 20856k
Garbage: 248775k -> 248772k
Leak: 53996k -> 53983k
Overhead: 43175k -> 43165k
GGC runs: 371 -> 370
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 558902k to 560187k, overall 0.23%
Overall memory needed: 95044k -> 95036k
Peak memory use before GGC: 86950k -> 86942k
Peak memory use after GGC: 85421k -> 85413k
Maximum of released memory in single GGC run: 20530k
Garbage: 558902k -> 560187k
Leak: 57743k -> 57730k
Overhead: 72605k -> 72672k
GGC runs: 595 -> 597
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 650944k to 652132k, overall 0.18%
Overall memory needed: 95040k -> 95024k
Peak memory use before GGC: 86951k -> 86943k
Peak memory use after GGC: 85422k -> 85414k
Maximum of released memory in single GGC run: 20531k
Garbage: 650944k -> 652132k
Leak: 58611k -> 58598k
Overhead: 90658k -> 90700k
GGC runs: 689 -> 690
comparing Gerald's testcase PR8361 compilation at -O3 level:
Amount of produced GGC garbage increased from 670667k to 672333k, overall 0.25%
Overall memory needed: 96120k -> 96064k
Peak memory use before GGC: 87880k -> 87872k
Peak memory use after GGC: 86712k -> 86704k
Maximum of released memory in single GGC run: 20795k
Garbage: 670667k -> 672333k
Leak: 59665k -> 59652k
Overhead: 93336k -> 93426k
GGC runs: 691
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-05-06 12:43:43.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-05-07 01:23:33.000000000 +0000
@@ -1,3 +1,83 @@
+2005-05-06 Eric Christopher <echristo@redhat.com>
+
+ * config/mips/mips.opt: Remove -mint64 option.
+ * config/mips/mips.c (override_options): Remove -mint64
+ handling.
+ * config/mips/mips.h (INT_TYPE_SIZE): Define to 32.
+ * config/mips/linux.h (TARGET_OS_CPP_BUILTINS): Remove
+ 64-bit integer handling.
+ * doc/invoke.texi (Option Summary): Remove -mint64 for
+ mips.
+
+2005-05-06 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR tree-optimization/19401
+ * tree-flow.h (tree_unroll_loops_completely): Declaration changed.
+ * tree-ssa-loop-ivcanon.c (enum unroll_level): New.
+ (estimated_unrolled_size): New function.
+ (try_unroll_loop_completely, canonicalize_loop_induction_variables,
+ tree_unroll_loops_completely): Always unroll loops if the code size
+ does not increase.
+ * tree-ssa-loop.c (tree_complete_unroll): Indicate whether all
+ loops should be unrolled completely.
+ (gate_tree_complete_unroll): Run complete unrolling unconditionally.
+
+2005-05-06 Zdenek Dvorak <dvorakz@suse.cz>
+
+ PR rtl-optimization/21254
+ * loop-iv.c (iv_number_of_iterations): Simplify infiniteness
+ assumptions for loops that otherwise do not roll.
+ (find_simple_exit): Prefer # of iterations that is guaranteed
+ not to be infinite.
+ * loop-unroll.c (decide_peel_once_rolling,
+ decide_peel_completely): Check whether the loop is infinite.
+
+2005-05-06 Pat Haugen <pthaugen@us.ibm.com>
+
+ * config/rs6000/sysv4.opt: Fix typo.
+
+2005-05-06 Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua>
+ Jakub Jelinek <jakub@redhat.com>
+
+ PR target/21329
+ * config/i386/i386.c (ix86_expand_movmem): Don't use rep; movsb
+ for -Os if (movsl;)*(movsw;)?(movsb;)? sequence is shorter.
+ Don't use rep; movs{l,q} if the repetition count is really small,
+ instead use a sequence of movs{l,q} instructions.
+
+2005-05-06 Jeff Law <law@redhat.com>
+
+ PR tree-optimization/21380
+ * tree-ssa-threadupdate.c (thread_through_all_blocks): Do not
+ thread through a block with no preds.
+
+2005-05-06 Kazu Hirata <kazu@cs.umass.edu>
+
+ * tree-ssa-operands.c (clobbered_v_may_defs, clobbered_vuses,
+ ro_call_vuse, fini_ssa_operands, add_call_clobber_ops,
+ add_call_read_ops): Use VEC instead of VARRAY.
+
+2005-05-06 Nathan Sidwell <nathan@codesourcery.com>
+
+ * config/mcore/mcore.c (mcore_print_operand_address): Use
+ gcc_assert and gcc_unreachable as appropriate.
+ (mcore_print_operand, mcore_gen_compare_reg, mcore_output_call,
+ mcore_output_andn, output_inline_const, mcore_output_move,
+ mcore_output_movedouble, mcore_expand_block_move,
+ layout_mcore_frame, mcore_initial_elimination_offset,
+ mcore_expand_prolog, mcore_mark_dllexport,
+ mcore_mark_dllimport): Likewise.
+ * config/mcore/mcore.h (switch_to_section): Likewise.
+ * config/mcore/mcore.md: Likewise.
+
+2005-05-06 Aldy Hernandez <aldyh@redhat.com>
+
+ * config/rs6000/linux64.h: Remove MASK_PROFILE_KERNEL, and
+ TARGET_PROFILE_KERNEL.
+
+ * config/rs6000/rs6000.c (output_profile_hook): Add comment to
+ TARGET_PROFILE_KERNEL use.
+
2005-05-06 Nathan Sidwell <nathan@codesourcery.com>
* config/m32r/m32r.c (m32r_encode_section_info): Use gcc_assert
@@ -189,7 +269,7 @@
2005-05-05 Kelley Cook <kcook@gcc.gnu.org>
- * config/m32r/xm-m32r.h, config/m32r/linux.h: Delete files.
+ * config/m32r/xm-m32r.h, config/m32r/xm-linux.h: Delete files.
2005-05-05 Kelley Cook <kcook@gcc.gnu.org>
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp 2005-05-06 00:06:21.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog 2005-05-07 01:23:42.000000000 +0000
@@ -1,3 +1,14 @@
+2005-05-06 Kazu Hirata <kazu@cs.umass.edu>
+
+ * decl2.c (spew_debug): Remove.
+
+ * decl2.c (ssdf_decls, start_static_storage_duration_function,
+ generate_ctor_or_dtor_function): Use VEC instead of VARRAY.
+
+ * decl2.c (pending_statics, note_vague_linkage_var,
+ cp_finish_file): Use VEC instead of VARRAY.
+ (pending_statics_used): Remove.
+
2005-05-05 Kazu Hirata <kazu@cs.umass.edu>
* decl2.c (deferred_fns, note_vague_linkage_fn,
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.