GCC memory consumption increased by recent patch!

gcctest@suse.de gcctest@suse.de
Sun Feb 13 03:21: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: 24657k -> 24661k
    Peak memory use before GGC: 9358k -> 9359k
    Peak memory use after GGC: 8672k -> 8673k
    Maximum of released memory in single GGC run: 2864k
    Garbage: 41650k -> 41665k
    Leak: 6410k -> 6395k
    Overhead: 5773k -> 5773k
    GGC runs: 327

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25509k -> 25513k
    Peak memory use before GGC: 9235k -> 9236k
    Peak memory use after GGC: 8739k -> 8740k
    Maximum of released memory in single GGC run: 2028k
    Garbage: 60284k -> 60286k
    Leak: 6755k -> 6752k
    Overhead: 9904k -> 9904k
    GGC runs: 500

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29153k
    Peak memory use before GGC: 12670k -> 12671k
    Peak memory use after GGC: 12544k -> 12545k
    Maximum of released memory in single GGC run: 2597k
    Garbage: 78459k -> 78452k
    Leak: 6591k -> 6593k
    Overhead: 14032k -> 14032k
    GGC runs: 511

comparing combine.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 31573k to 31605k, overall 0.10%
  Amount of memory still referenced at the end of compilation increased from 7099k to 7117k, overall 0.24%
    Overall memory needed: 31573k -> 31605k
    Peak memory use before GGC: 12772k -> 12773k
    Peak memory use after GGC: 12544k -> 12545k
    Maximum of released memory in single GGC run: 3407k
    Garbage: 105855k -> 105846k
    Leak: 7099k -> 7117k
    Overhead: 18832k -> 18832k
    GGC runs: 581 -> 580

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 114136k
    Peak memory use before GGC: 74746k -> 74747k
    Peak memory use after GGC: 45492k -> 45493k
    Maximum of released memory in single GGC run: 39340k
    Garbage: 152670k -> 152668k
    Leak: 10983k -> 10984k
    Overhead: 19970k -> 19970k
    GGC runs: 274

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 124228k
    Peak memory use before GGC: 78755k -> 78756k
    Peak memory use after GGC: 70102k -> 70103k
    Maximum of released memory in single GGC run: 40779k
    Garbage: 366124k -> 366124k
    Leak: 11360k -> 11361k
    Overhead: 69303k -> 69303k
    GGC runs: 396

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 147352k -> 147340k
    Peak memory use before GGC: 98359k -> 98356k
    Peak memory use after GGC: 83476k -> 83473k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 480527k -> 480544k
    Leak: 11249k -> 11242k
    Overhead: 84546k -> 84547k
    GGC runs: 340

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 147372k -> 147360k
    Peak memory use before GGC: 98361k -> 98358k
    Peak memory use after GGC: 83478k -> 83475k
    Maximum of released memory in single GGC run: 39384k
    Garbage: 481342k -> 481358k
    Leak: 11286k -> 11279k
    Overhead: 84676k -> 84676k
    GGC runs: 346

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 111052k -> 111056k
    Peak memory use before GGC: 87155k -> 87156k
    Peak memory use after GGC: 85894k -> 85895k
    Maximum of released memory in single GGC run: 19511k
    Garbage: 246084k -> 246085k
    Leak: 55521k -> 55523k
    Overhead: 43324k -> 43324k
    GGC runs: 366

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 103893k -> 103905k
    Peak memory use before GGC: 86013k -> 86014k
    Peak memory use after GGC: 85112k -> 85113k
    Maximum of released memory in single GGC run: 18951k
    Garbage: 433536k -> 433597k
    Leak: 56855k -> 56857k
    Overhead: 64544k -> 64546k
    GGC runs: 511

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 104121k -> 104129k
    Peak memory use before GGC: 86013k -> 86014k
    Peak memory use after GGC: 85113k -> 85114k
    Maximum of released memory in single GGC run: 18951k
    Garbage: 476214k -> 476262k
    Leak: 57423k -> 57423k
    Overhead: 74277k -> 74278k
    GGC runs: 573

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 105205k -> 105209k
    Peak memory use before GGC: 87149k -> 87150k
    Peak memory use after GGC: 86192k -> 86193k
    Maximum of released memory in single GGC run: 19400k
    Garbage: 480837k -> 480830k
    Leak: 57560k -> 57569k
    Overhead: 74876k -> 74875k
    GGC runs: 557

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2005-02-12 03:32:49.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2005-02-12 14:45:06.000000000 +0000
@@ -1,3 +1,64 @@
+2005-02-12  Ira Rosen  <irar@il.ibm.com>
+
+	* tree-vectorizer.c (vect_get_base_and_offset): Remove.
+	(vect_is_simple_iv_evolution): Remove redundant parameter
+	and step check.
+	(vect_analyze_scalar_cycles): Call vect_is_simple_iv_evolution
+	without last parameter.
+	(vect_analyze_pointer_ref_access): Get access_fn as parameter.
+	Return pointer step. Call vect_is_simple_iv_evolution without
+	last parameter. Check only that the step is multiple of size
+	type. Remove stmt_vinfo updates.
+	(vect_get_memtag_and_dr): Remove.
+	(vect_get_memtag): New function.
+	(vect_address_analysis): New function.
+	(vect_object_analysis): New function.
+	(vect_analyze_data_refs): Call vect_object_analysis and
+	vect_get_memtag. Update stmt_vinfo fields.
+
+2005-02-12  Ira Rosen  <irar@il.ibm.com>
+
+	* tree-data-ref.c (array_base_name_differ_p): Check that the bases
+	exist and are objects. Remove checks for pointer.
+	* tree-vectorizer.c (vect_create_addr_base_for_vector_ref): Use
+	STMT_VINFO_VECT_DR_BASE_ADDRESS instead of DR_BASE_NAME.
+	(vect_create_data_ref_ptr): Likewise.
+	(vect_base_addr_differ_p): New function.
+	(vect_analyze_data_ref_dependence): Call vect_base_addr_differ_p.
+	(vect_analyze_pointer_ref_access): Add output parameter - ptr_init.
+	Don't set the DR_BASE_NAME field of data-ref.
+	(vect_get_memtag_and_dr): Use ptr_init instead of DR_BASE_NAME.
+
+2005-02-12  Uros Bizjak  <uros@kss-loka.si>
+
+	* optabs.h (enum optab_index): Add new OTI_ldexp.
+	(ldexp_optab): Define corresponding macro.
+	* optabs.c (init_optabs): Initialize ldexp_optab.
+	* genopinit.c (optabs): Implement ldexp_optab using ldexp?f3
+	patterns.
+	* builtins.c (expand_builtin_mathfn_2): Handle BUILT_IN_LDEXP{,F,L}
+	using ldexp_optab.
+	(expand_builtin): Expand BUILT_IN_LDEXP{,F,L} using
+	expand_builtin_mathfn_2 if flag_unsafe_math_optimizations is set.
+
+	* config/i386/i386.md (ldexpsf3, ldexpdf3, ldexpxf3): New expanders
+	to implement ldexpf, ldexp and ldexpl built-ins as inline x87
+	intrinsics.
+
+2005-02-12  Ira Rosen  <irar@il.ibm.com>
+
+	* tree-vectorizer.h (struct _stmt_vec_info): Rename a field: base
+	to base_address.
+	* tree-vectorizer.c (new_stmt_vec_info): Rename the above field of
+	stmt_vec_info.
+	(vect_get_base_and_offset): Always return an address.
+	(vect_create_addr_base_for_vector_ref): Remove treatment for
+	different data reference types.
+	(vect_compute_data_ref_alignment): Rename base to base_address in
+	stmt_vec_info. Get the object in order to force its alignment.
+	(vect_get_memtag_and_dr): Rename base to base_address in
+	stmt_vec_info. Extract the object for memtag analysis.
+
 2005-02-12  Hans-Peter Nilsson  <hp@axis.com>
 
 	PR regression/19898.

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