This is the mail archive of the gcc-regression@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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: 25233k -> 25241k
    Peak memory use before GGC: 9329k
    Peak memory use after GGC: 8641k
    Maximum of released memory in single GGC run: 2926k
    Garbage: 42515k
    Leak: 6088k
    Overhead: 5657k
    GGC runs: 354

comparing combine.c compilation at -O1 level:
    Overall memory needed: 26513k -> 26525k
    Peak memory use before GGC: 9205k
    Peak memory use after GGC: 8733k
    Maximum of released memory in single GGC run: 2066k
    Garbage: 69782k
    Leak: 6480k
    Overhead: 11359k
    GGC runs: 555

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29829k -> 29841k
    Peak memory use before GGC: 12705k
    Peak memory use after GGC: 12579k
    Maximum of released memory in single GGC run: 2576k
    Garbage: 84780k
    Leak: 6303k
    Overhead: 15985k
    GGC runs: 562

comparing combine.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 21132k to 21392k, overall 1.23%
    Overall memory needed: 21132k -> 21392k
    Peak memory use before GGC: 13093k
    Peak memory use after GGC: 12579k
    Maximum of released memory in single GGC run: 3413k
    Garbage: 113749k
    Leak: 6845k
    Overhead: 21057k
    GGC runs: 629

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 118512k
    Peak memory use before GGC: 79408k
    Peak memory use after GGC: 46137k
    Maximum of released memory in single GGC run: 43357k
    Garbage: 161088k
    Leak: 10609k
    Overhead: 20460k
    GGC runs: 295

comparing insn-attrtab.c compilation at -O1 level:
  Overall memory allocated via mmap and sbrk increased from 125048k to 125308k, overall 0.21%
    Overall memory needed: 125048k -> 125308k
    Peak memory use before GGC: 86894k
    Peak memory use after GGC: 70491k
    Maximum of released memory in single GGC run: 41161k
    Garbage: 430920k
    Leak: 10956k
    Overhead: 80011k
    GGC runs: 441

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 151484k -> 151480k
    Peak memory use before GGC: 102310k
    Peak memory use after GGC: 85907k
    Maximum of released memory in single GGC run: 42321k
    Garbage: 477316k
    Leak: 10883k
    Overhead: 88016k
    GGC runs: 362

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 151484k
    Peak memory use before GGC: 102312k
    Peak memory use after GGC: 85909k
    Maximum of released memory in single GGC run: 42322k
    Garbage: 478589k
    Leak: 10927k
    Overhead: 88206k
    GGC runs: 371

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 112784k
    Peak memory use before GGC: 89431k
    Peak memory use after GGC: 88443k
    Maximum of released memory in single GGC run: 19812k
    Garbage: 250165k
    Leak: 57105k
    Overhead: 45841k
    GGC runs: 363

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 95348k
    Peak memory use before GGC: 88431k
    Peak memory use after GGC: 87373k
    Maximum of released memory in single GGC run: 19437k
    Garbage: 595564k
    Leak: 59145k
    Overhead: 133258k
    GGC runs: 628

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 95684k
    Peak memory use before GGC: 88431k
    Peak memory use after GGC: 87373k
    Maximum of released memory in single GGC run: 19437k
    Garbage: 651671k
    Leak: 59735k
    Overhead: 158238k
    GGC runs: 675

comparing Gerald's testcase PR8361 compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 103024k to 103196k, overall 0.17%
    Overall memory needed: 103024k -> 103196k
    Peak memory use before GGC: 95610k
    Peak memory use after GGC: 88661k
    Maximum of released memory in single GGC run: 20248k
    Garbage: 699713k
    Leak: 60125k
    Overhead: 172044k
    GGC runs: 664

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-11-04 01:30:01.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-11-04 06:05:53.000000000 +0000
@@ -1,3 +1,58 @@
+2004-11-03  Dorit Naishlos  <dorit@il.ibm.com>
+
+	PR tree-optimization/18009
+	* tree-vectorizer.h (enum dr_alignment_support): New type.
+	(MAX_NUMBER_OF_UNALIGNED_DATA_REFS): Removed.
+	(LOOP_UNALIGNED_DR): replaced with LOOP_VINFO_UNALIGNED_DR and holds a
+	single data_reference (instead of a varray of references).
+	* tree-vectorizer.c (new_loop_vec_info): Likewise.
+	(vect_gen_niters_for_prolog_loop): Likewise.
+	(vect_update_inits_of_drs): Likewise.
+
+	(vect_update_inits_of_drs): Setting of DR_MISALIGNMENT moved to
+	vect_enhance_data_refs_alignment.
+	(vect_do_peeling_for_alignment): Likewise.
+	(vect_enhance_data_refs_alignment): Decide if and by how much to peel;
+	this functionality used to be in vect_analyze_data_refs_alignment.
+	Also update DR_MISALIGNMENT due to peeling; this functionality used to
+	be in vect_update_inits_of_drs and vect_do_peeling_for_alignment).
+	(vect_analyze_data_refs_alignment): Decision on whether and by how much
+	to peel moved to vect_enhance_data_refs_alignment. Call 
+	vect_supportable_dr_alignment.
+
+	(vect_compute_data_ref_alignment): Set STMT_VINFO_VECTYPE.
+	(vect_compute_data_refs_alignment): Return bool. Consider return value
+	of vect_compute_data_ref_alignment and return true/false accordingly.
+	(vect_enhance_data_refs_alignment): Consider return value of 
+	vect_compute_data_refs_alignment and return true/false accordingly.
+
+	(vect_supportable_dr_alignment): New function.
+	(vectorizable_store): Call vect_supportable_dr_alignment.
+	(vectorizable_load): Call vect_supportable_dr_alignment. Alignment
+	support checks moved from here to vect_supportable_dr_alignment.
+
+	(vect_transform_loop): Avoid 80 columns overflow.
+
+2004-11-03  Andrew Pinski  <pinskia@physics.uc.edu>
+
+	* timevar.c (timevar_enable): Change from
+	static.
+	(timevar_push): Rename to ...
+	(timevar_push_1): this and remove the
+	enabled check.
+	(timevar_pop): Rename to ...
+	(timevar_pop_1): this and remove the
+	enabled check.
+	* timevar.h (POP_TIMEVAR_AND_RETURN): Use do/while loops.
+	(timevar_pop): New macro.
+	(timevar_push): New macro.
+	(timevar_enable): Declare.
+
+2004-11-03  Andrew Pinski  <pinskia@physics.uc.edu>
+
+	* config/darwin.h (REAL_LIBGCC_SPEC): Define to use shared
+	libgcc for shared libraries.
+
 2004-11-03  Ulrich Weigand  <uweigand@de.ibm.com>
 
 	* config/s390/s390-protos.h (s390_split_access_reg): Add prototype.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]