Re: A recent patch increased GCC's memory consumption!

[Jan Hubicka <jh at suse dot cz>]

> 
> comparing insn-attrtab.c compilation at -O0 level:
>   Amount of memory still referenced at the end of compilation increased from 9518k to 9885k, overall 3.85%

Hmm,
looks like it is the vector change.  I wonder if we can't cut them down
to VARRAY memory usage and/or avoid aliasing datastructures at -O0
completely?

Honza
>     Overall memory needed: 82164k
>     Peak memory use before GGC: 69036k
>     Peak memory use after GGC: 44790k
>     Maximum of released memory in single GGC run: 36009k
>     Garbage: 141276k -> 140382k
>     Leak: 9518k -> 9885k
>     Overhead: 20524k -> 20394k
>     GGC runs: 242 -> 239
> 
> comparing insn-attrtab.c compilation at -O1 level:
>   Amount of memory still referenced at the end of compilation increased from 9886k to 10065k, overall 1.81%
>     Overall memory needed: 105332k -> 105340k
>     Peak memory use before GGC: 85337k -> 85347k
>     Peak memory use after GGC: 79185k -> 79195k
>     Maximum of released memory in single GGC run: 32286k
>     Garbage: 284671k -> 283067k
>     Leak: 9886k -> 10065k
>     Overhead: 33800k -> 33382k
>     GGC runs: 239
> 
> comparing insn-attrtab.c compilation at -O2 level:
>   Amount of memory still referenced at the end of compilation increased from 9867k to 10051k, overall 1.87%
>     Overall memory needed: 107856k -> 107912k
>     Peak memory use before GGC: 89750k -> 89760k
>     Peak memory use after GGC: 81639k -> 81649k
>     Maximum of released memory in single GGC run: 30736k
>     Garbage: 333354k -> 330591k
>     Leak: 9867k -> 10051k
>     Overhead: 41406k -> 40625k
>     GGC runs: 265 -> 264
> 
> comparing insn-attrtab.c compilation at -O3 level:
>   Amount of memory still referenced at the end of compilation increased from 9871k to 10056k, overall 1.87%
>     Overall memory needed: 107964k -> 107928k
>     Peak memory use before GGC: 89776k -> 89786k
>     Peak memory use after GGC: 81665k -> 81675k
>     Maximum of released memory in single GGC run: 31062k -> 30934k
>     Garbage: 333963k -> 331201k
>     Leak: 9871k -> 10056k
>     Overhead: 41602k -> 40821k
>     GGC runs: 269 -> 268
> 
> comparing Gerald's testcase PR8361 compilation at -O0 level:
>     Overall memory needed: 118260k
>     Peak memory use before GGC: 95032k
>     Peak memory use after GGC: 94083k
>     Maximum of released memory in single GGC run: 20360k
>     Garbage: 218764k -> 218496k
>     Leak: 49504k -> 49513k
>     Overhead: 38051k -> 37972k
>     GGC runs: 363
> 
> comparing Gerald's testcase PR8361 compilation at -O1 level:
>     Overall memory needed: 115856k
>     Peak memory use before GGC: 97679k
>     Peak memory use after GGC: 96699k
>     Maximum of released memory in single GGC run: 18987k
>     Garbage: 464248k -> 463624k
>     Leak: 52782k -> 52800k
>     Overhead: 51584k -> 51424k
>     GGC runs: 509
> 
> comparing Gerald's testcase PR8361 compilation at -O2 level:
>     Overall memory needed: 115836k -> 115848k
>     Peak memory use before GGC: 97678k -> 97679k
>     Peak memory use after GGC: 96699k -> 96700k
>     Maximum of released memory in single GGC run: 18987k
>     Garbage: 553187k -> 552446k
>     Leak: 53674k -> 53701k
>     Overhead: 60344k -> 60154k
>     GGC runs: 589
> 
> comparing Gerald's testcase PR8361 compilation at -O3 level:
>     Overall memory needed: 117136k -> 117132k
>     Peak memory use before GGC: 98974k -> 98973k
>     Peak memory use after GGC: 97994k -> 97993k
>     Maximum of released memory in single GGC run: 19240k
>     Garbage: 573108k -> 572423k
>     Leak: 54030k -> 54058k
>     Overhead: 61315k -> 61151k
>     GGC runs: 599
> 
> Head of the ChangeLog is:
> 
> --- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2006-04-17 09:13:31.000000000 +0000
> +++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2006-04-17 19:59:15.000000000 +0000
> @@ -1,3 +1,33 @@
> +2006-04-17  Roger Sayle  <roger@eyesopen.com>
> +
> +	* expr.c (expand_assignment): Optimize away no-op moves where the
> +	source and destination are equal and have no side-effects.
> +
> +2006-04-17  Richard Guenther  <rguenther@suse.de>
> +
> +	PR target/26826
> +	* reload.c (push_reload): Guard calls to get_secondary_mem
> +	for memory subregs.
> +
> +2006-04-16  Kazu Hirata  <kazu@codesourcery.com>
> +
> +	* alias.c (reg_base_value, old_reg_base_value): Change the
> +	type to VEC(rtx,gc) *.
> +	(REG_BASE_VALUE, find_base_value, record_set,
> +	init_alias_analysis): Use VEC instead of VARRAY.
> +
> +	* alias.c (alias_sets): Change the type to
> +	VEC(alias_set_entry,gc) *.
> +	(get_alias_set_entry, new_alias_set, record_alias_subset): Use
> +	VEC instead of VARRAY.
> +	(last_alias_set): Remove.
> +
> +	* cgraph.h (cgraph_edge_p): New.
> +	Update the prototype of cgraph_function_versioning.
> +	* cgraphunit.c (cgraph_copy_node_for_versioning,
> +	cgraph_function_versioning): Use VEC instead of VARRAY.
> +	* ipa-cp.c (ipcp_insert_stage): Likewise.
> +
>  2006-04-16  Roger Sayle  <roger@eyesopen.com>
>  
>  	PR target/26961
> --- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog.cp	2006-04-16 22:28:20.000000000 +0000
> +++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/cp/ChangeLog	2006-04-17 19:59:15.000000000 +0000
> @@ -1,3 +1,13 @@
> +2006-04-17  Janis Johnson  <janis187@us.ibm.com>
> +
> +	PR c++/26114, c++/26115
> +	* typeck.c (cxx_mark_addressable): Restore check for extra_warnings.
> +	* class.c (check_field_decls): Ditto.
> +
> +2006-04-17  Volker Reichelt  <reichelt@igpm.rwth-aachen.de>
> +
> +	* init.c (build_offset_ref): Remove superfluous temporary.
> +
>  2006-04-16  Mark Mitchell  <mark@codesourcery.com>
>  
>  	PR c++/26365
> @@ -4773,7 +4783,7 @@
>  	* pt.c (instantiate_class_template,
>  	resolve_typename_type): Likewise.
>  
> -2005-01-03  Volker Reichelt  <reichelt@igpm.rwth-aaachen.de>
> +2005-01-03  Volker Reichelt  <reichelt@igpm.rwth-aachen.de>
>  
>  	PR c++/14136
>  	* parser.c (cp_parser_unqualified_id): Do not issue error message
> 
> 
> 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.