This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
Some aspect of 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: Wed, 11 May 2005 08:02:45 +0000
- Subject: Some aspect of 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: 9439k
Peak memory use after GGC: 8752k
Maximum of released memory in single GGC run: 2797k
Garbage: 42285k
Leak: 6487k
Overhead: 5875k
GGC runs: 326
comparing combine.c compilation at -O1 level:
Peak amount of GGC memory allocated before garbage collecting increased from 8787k to 8890k, overall 1.17%
Amount of produced GGC garbage increased from 60398k to 63560k, overall 5.24%
Amount of memory still referenced at the end of compilation increased from 6838k to 6847k, overall 0.13%
Overall memory needed: 27180k -> 27396k
Peak memory use before GGC: 8787k -> 8890k
Peak memory use after GGC: 8553k -> 8548k
Maximum of released memory in single GGC run: 2170k -> 2235k
Garbage: 60398k -> 63560k
Leak: 6838k -> 6847k
Overhead: 7578k -> 7729k
GGC runs: 500 -> 524
comparing combine.c compilation at -O2 level:
Amount of produced GGC garbage increased from 85707k to 88642k, overall 3.42%
Overall memory needed: 19952k
Peak memory use before GGC: 12764k
Peak memory use after GGC: 12634k
Maximum of released memory in single GGC run: 2618k -> 2625k
Garbage: 85707k -> 88642k
Leak: 6656k -> 6653k
Overhead: 10963k -> 11082k
GGC runs: 524 -> 539
comparing combine.c compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting increased from 14713k to 15325k, overall 4.16%
Amount of produced GGC garbage increased from 118975k to 123445k, overall 3.76%
Overall memory needed: 23088k -> 22788k
Peak memory use before GGC: 14713k -> 15325k
Peak memory use after GGC: 12944k -> 12917k
Maximum of released memory in single GGC run: 3069k -> 3092k
Garbage: 118975k -> 123445k
Leak: 7119k -> 7102k
Overhead: 15154k -> 15293k
GGC runs: 591 -> 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
Leak: 11186k
Overhead: 19889k
GGC runs: 268
comparing insn-attrtab.c compilation at -O1 level:
Overall memory allocated via mmap and sbrk increased from 99368k to 103548k, overall 4.21%
Peak amount of GGC memory allocated before garbage collecting increased from 72838k to 81339k, overall 11.67%
Peak amount of GGC memory still allocated after garbage collectin increased from 64736k to 66512k, overall 2.74%
Overall memory needed: 99368k -> 103548k
Peak memory use before GGC: 72838k -> 81339k
Peak memory use after GGC: 64736k -> 66512k
Maximum of released memory in single GGC run: 37092k -> 35980k
Garbage: 308909k -> 308184k
Leak: 11478k -> 11470k
Overhead: 38026k -> 37961k
GGC runs: 375 -> 386
comparing insn-attrtab.c compilation at -O2 level:
Peak amount of GGC memory allocated before garbage collecting run decreased from 116905k to 107838k, overall -8.41%
Peak amount of GGC memory still allocated after garbage collecting decreased from 88272k to 82700k, overall -6.74%
Amount of produced GGC garbage decreased from 425823k to 404704k, overall -5.22%
Amount of memory still referenced at the end of compilation increased from 11280k to 11434k, overall 1.36%
Overall memory needed: 142452k -> 140412k
Peak memory use before GGC: 116905k -> 107838k
Peak memory use after GGC: 88272k -> 82700k
Maximum of released memory in single GGC run: 35225k -> 35344k
Garbage: 425823k -> 404704k
Leak: 11280k -> 11434k
Overhead: 52918k -> 50829k
GGC runs: 332 -> 336
comparing insn-attrtab.c compilation at -O3 level:
Peak amount of GGC memory allocated before garbage collecting run decreased from 116907k to 107838k, overall -8.41%
Peak amount of GGC memory still allocated after garbage collecting decreased from 88274k to 82703k, overall -6.74%
Amount of produced GGC garbage decreased from 426580k to 405481k, overall -5.20%
Amount of memory still referenced at the end of compilation increased from 11310k to 11454k, overall 1.27%
Overall memory needed: 142464k -> 140420k
Peak memory use before GGC: 116907k -> 107838k
Peak memory use after GGC: 88274k -> 82703k
Maximum of released memory in single GGC run: 35225k -> 35344k
Garbage: 426580k -> 405481k
Leak: 11310k -> 11454k
Overhead: 53041k -> 50951k
GGC runs: 337 -> 343
comparing Gerald's testcase PR8361 compilation at -O0 level:
Overall memory needed: 112460k
Peak memory use before GGC: 87827k
Peak memory use after GGC: 86409k
Maximum of released memory in single GGC run: 20839k
Garbage: 248055k
Leak: 53983k
Overhead: 43233k
GGC runs: 370
comparing Gerald's testcase PR8361 compilation at -O1 level:
Amount of produced GGC garbage increased from 555117k to 567916k, overall 2.31%
Overall memory needed: 95036k
Peak memory use before GGC: 86942k
Peak memory use after GGC: 85413k
Maximum of released memory in single GGC run: 20531k
Garbage: 555117k -> 567916k
Leak: 57726k -> 57427k
Overhead: 72051k -> 72998k
GGC runs: 592 -> 611
comparing Gerald's testcase PR8361 compilation at -O2 level:
Amount of produced GGC garbage increased from 646953k to 662190k, overall 2.36%
Overall memory needed: 95020k -> 95028k
Peak memory use before GGC: 86942k
Peak memory use after GGC: 85413k
Maximum of released memory in single GGC run: 20530k
Garbage: 646953k -> 662190k
Leak: 58598k -> 58233k
Overhead: 90056k -> 91381k
GGC runs: 687 -> 703
comparing Gerald's testcase PR8361 compilation at -O3 level:
Amount of produced GGC garbage increased from 667007k to 682139k, overall 2.27%
Overall memory needed: 95944k -> 96100k
Peak memory use before GGC: 87872k
Peak memory use after GGC: 86704k
Maximum of released memory in single GGC run: 20795k
Garbage: 667007k -> 682139k
Leak: 59651k -> 59010k
Overhead: 92845k -> 94161k
GGC runs: 687 -> 706
Head of changelog is:
--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog 2005-05-10 18:18:53.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog 2005-05-11 07:00:29.000000000 +0000
@@ -1,3 +1,92 @@
+2005-05-10 Matt Kraai <kraai@ftbfs.org>
+
+ * Makefile.in (gtype-desc.o, build/genautomata.o)
+ (build/varray.o): Depend on $(VARRAY_H).
+
+2005-05-10 Diego Novillo <dnovillo@redhat.com>
+
+ * tree-optimize.c (init_tree_optimization_passes): Re-organize
+ optimization passes to do an initial batch of scalar cleanups.
+
+2005-05-10 Ian Lance Taylor <ian@airs.com>
+
+ * read-rtl.c (struct macro_traverse_data): Define.
+ (map_attr_string): New static function, broken out of
+ apply_macro_to_string.
+ (mode_attr_index, apply_mode_maps): New static functions.
+ (apply_macro_to_string): Call map_attr_string.
+ (apply_macro_to_rtx): Add mode_maps and infile parameters. Change
+ all callers.
+ (apply_macro_traverse): Expect data to point to a struct
+ macro_traverse_data.
+ (read_rtx): Add mode_maps local variable. Use mode_traverse_data
+ to pass data through htab_traverse.
+ (read_rtx_1): Add mode_maps parameter. Change all callers.
+ Handle mode names which are attribute strings.
+ * doc/md.texi (Substitutions): Rename from String Substitutions.
+ Change references. Document using attributes as modes.
+
+2005-05-10 Zdenek Dvorak <dvorakz@suse.cz>
+
+ * tree-cfg.c (tree_duplicate_sese_region): Update profile.
+ * tree-optimize.c (init_tree_optimization_passes) Swap
+ pass_ch and pass_profile.
+ * tree-ssa-loop-ch.c (copy_loop_headers): Do not update profile
+ here. Remove rewrite_into_loop_closed_ssa call.
+
+2005-05-10 Adrian Straetling <straetling@de.ibm.com>
+
+ * config/s390/s390.c: (s390_const_double_ok_for_constraint_p): New
+ function.
+ (legitimate_reload_constant_p): Add check for const double zero.
+ * config/s390/s390.md: Add comment for constraint letter 'G'.
+ ("*movdf_64", "*movdf_31", "movsf"): Add constraint and proper
+ attributes for new case.
+ * config/s390/s390.h: (CONST_DOUBLE_OK_FOR_CONSTRAINT_P): Define it as
+ s390_const_double_ok_for_constraint_p.
+ * config/s390/s390-protos.h (s390_const_double_ok_for_constraint_p):
+ Add prototype.
+
+2005-05-10 Kazu Hirata <kazu@cs.umass.edu>
+
+ PR tree-optimization/21170
+ * tree-ssa-dom.c, tree-ssa-threadupdate.c: Replace
+ rewrite_ssa_into_ssa in comments with update_ssa.
+
+2005-05-10 Zdenek Dvorak <dvorakz@suse.cz>
+
+ * tree-ssa-loop-im.c: Include hashtab.h.
+ (struct mem_ref_loc): New.
+ (struct mem_ref): Describe the set of references with the same
+ shape.
+ (max_stmt_uid, get_stmt_uid, record_mem_ref, free_mem_refs,
+ maybe_queue_var, fem_single_reachable_address,
+ for_each_memref, single_reachable_address,
+ is_call_clobbered_ref, determine_lsm_reg): Removed.
+ (record_mem_ref_loc, free_mem_ref_locs, determine_lsm_ref,
+ hoist_memory_reference, memref_hash, memref_eq, memref_del,
+ gather_mem_refs_stmt, gather_mem_refs, find_more_ref_vops):
+ New functions.
+ (rewrite_mem_refs, schedule_sm): Use mem_ref_loc list.
+ (determine_lsm_loop): Rewritten.
+ (determine_lsm): Do not set stmt uids.
+
+2005-05-10 Adrian Straetling <straetling@de.ibm.com>
+
+ * config/s390/s390.md: Add comment lines for 'f' and 't' constraint
+ letters.
+
+2005-05-10 Adrian Straetling <straetling@de.ibm.com>
+
+ * config/s390/s390.md: ("anddi3","andsi3","andhi3","andqi3"): Merge.
+ ("iordi3", "iorsi3", "iorhi3", "iorqi3"): Merge.
+ ("xordi3", "xorsi3", "xorhi3", "xorqi3"): Merge.
+
+2005-05-10 Jeff Law <law@redhat.com>
+
+ * tree-ssa-dom.c (dom_opt_finalize_block): Do not call
+ thread_across_edge for any abnormal edges.
+
2005-05-10 Richard Henderson <rth@redhat.com>
* config/ia64/ia64.c (ia64_expand_atomic_op): New.
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.