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: 24577k
    Peak memory use before GGC: 9310k
    Peak memory use after GGC: 8624k
    Maximum of released memory in single GGC run: 2912k
    Garbage: 42433k
    Leak: 6088k
    Overhead: 5717k
    GGC runs: 353

comparing combine.c compilation at -O1 level:
    Overall memory needed: 25493k -> 25505k
    Peak memory use before GGC: 9198k
    Peak memory use after GGC: 8720k
    Maximum of released memory in single GGC run: 2060k
    Garbage: 68029k -> 68005k
    Leak: 6484k -> 6484k
    Overhead: 10667k -> 10666k
    GGC runs: 545

comparing combine.c compilation at -O2 level:
    Overall memory needed: 29089k
    Peak memory use before GGC: 12705k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 2574k
    Garbage: 82245k -> 82223k
    Leak: 6301k -> 6301k
    Overhead: 14828k -> 14821k
    GGC runs: 547

comparing combine.c compilation at -O3 level:
  Overall memory allocated via mmap and sbrk increased from 31509k to 31545k, overall 0.11%
    Overall memory needed: 31509k -> 31545k
    Peak memory use before GGC: 12987k
    Peak memory use after GGC: 12578k
    Maximum of released memory in single GGC run: 3408k -> 3407k
    Garbage: 111172k -> 111155k
    Leak: 6832k -> 6832k
    Overhead: 19906k -> 19903k
    GGC runs: 614

comparing insn-attrtab.c compilation at -O0 level:
    Overall memory needed: 118468k
    Peak memory use before GGC: 79386k
    Peak memory use after GGC: 46137k
    Maximum of released memory in single GGC run: 43335k
    Garbage: 161980k
    Leak: 10609k
    Overhead: 21242k
    GGC runs: 296

comparing insn-attrtab.c compilation at -O1 level:
    Overall memory needed: 129428k -> 129432k
    Peak memory use before GGC: 83952k
    Peak memory use after GGC: 70040k
    Maximum of released memory in single GGC run: 41104k
    Garbage: 445754k
    Leak: 10955k
    Overhead: 79294k
    GGC runs: 430

comparing insn-attrtab.c compilation at -O2 level:
    Overall memory needed: 154048k -> 153912k
    Peak memory use before GGC: 99964k
    Peak memory use after GGC: 85453k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 492646k -> 492644k
    Leak: 10875k -> 10875k
    Overhead: 87569k -> 87569k
    GGC runs: 364

comparing insn-attrtab.c compilation at -O3 level:
    Overall memory needed: 154056k -> 153920k
    Peak memory use before GGC: 99966k
    Peak memory use after GGC: 85455k
    Maximum of released memory in single GGC run: 42091k
    Garbage: 493925k -> 493908k
    Leak: 10920k -> 10918k
    Overhead: 87750k -> 87733k
    GGC runs: 372

comparing Gerald's testcase PR8361 compilation at -O0 level:
    Overall memory needed: 113404k
    Peak memory use before GGC: 89921k
    Peak memory use after GGC: 89026k
    Maximum of released memory in single GGC run: 19894k
    Garbage: 248747k
    Leak: 57792k
    Overhead: 45383k
    GGC runs: 362

comparing Gerald's testcase PR8361 compilation at -O1 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88916k
    Peak memory use after GGC: 87943k
    Maximum of released memory in single GGC run: 19401k
    Garbage: 552586k -> 552438k
    Leak: 59826k -> 59823k
    Overhead: 115292k -> 115281k
    GGC runs: 611

comparing Gerald's testcase PR8361 compilation at -O2 level:
    Overall memory needed: 95920k
    Peak memory use before GGC: 88916k
    Peak memory use after GGC: 87944k
    Maximum of released memory in single GGC run: 19401k
    Garbage: 601806k -> 601684k
    Leak: 60408k -> 60405k
    Overhead: 137348k -> 137310k
    GGC runs: 653 -> 652

comparing Gerald's testcase PR8361 compilation at -O3 level:
    Overall memory needed: 98316k -> 98284k
    Peak memory use before GGC: 90313k
    Peak memory use after GGC: 88776k
    Maximum of released memory in single GGC run: 20091k
    Garbage: 641873k -> 641542k
    Leak: 60748k -> 60744k
    Overhead: 148769k -> 148683k
    GGC runs: 646 -> 645

Head of changelog is:

--- /usr/src/SpecTests/sandbox-britten-memory/x86_64/mem-result/ChangeLog	2004-12-18 18:51:52.000000000 +0000
+++ /usr/src/SpecTests/sandbox-britten-memory/gcc/gcc/ChangeLog	2004-12-18 23:27:40.000000000 +0000
@@ -1,3 +1,69 @@
+2004-12-18  Eric Botcazou  <ebotcazou@libertysurf.fr>
+
+	PR middle-end/15486
+	* varasm.c (asm_emit_uninitialised): Return early if
+	a custom section is requested.
+	(assemble_variable): Revert 2002-03-15 patch.
+
+2004-12-18  Richard Henderson  <rth@redhat.com>
+
+	* stor-layout.c (layout_decl): Use unshare_expr, not unsave_expr.
+
+2004-12-18  Zdenek Dvorak  <dvorakz@suse.cz>
+
+        PR tree-optimization/18800
+        * params.def (PARAM_IV_ALWAYS_PRUNE_CAND_SET_BOUND): New parameter.
+        * tree-ssa-loop-ivopts.c (struct iv_ca): Add n_cands field.
+        (ALWAYS_PRUNE_CAND_SET_BOUND): New macro.
+        (iv_ca_set_no_cp, iv_ca_set_cp, iv_ca_new): Update n_cands field.
+        (iv_ca_delta_join, iv_ca_delta_reverse, iv_ca_n_cands, iv_ca_prune):
+        New functions.
+        (iv_ca_extend): Return number of candidates in the set.
+        (try_add_cand_for): Add argument to iv_ca_extend calls.
+        (try_improve_iv_set): Use iv_ca_prune.
+        * doc/invoke.texi (iv-always-prune-cand-set-bound): Document.
+
+2004-12-18  Zdenek Dvorak  <dvorakz@suse.cz>
+
+	PR rtl-optimization/19001
+	* loop-iv.c (iv_number_of_iterations): Record assumptions for loops
+	with power of two step to 'infinite' field.
+
+2004-12-18  Roger Sayle  <roger@eyesopen.com>
+
+	* Makefile.in (stor-layout.o): Depend upon gt-stor-layout.h.
+	(tree-ssa-propagate.o): Depend upon gt-tree-ssa-propagate.h.
+	(tree-ssa-operands.o): Depend upon gt-tree-ssa-operands.h.
+	(tree-mudflap.o): Depend upon gt-tree-mudflap.h.
+	(expr.o): Depend upon gt-expr.h.
+	(regclass.o): Depend upon gt-regclass.h.
+	(bitmap.o): Depend upon gt-bitmap.h.
+	(lists.o): Depend upon gt-lists.h.
+
+	(cfgexpand.o): Don't depend upon gt-tree-cfg.h.
+
+	(GTFILES): Remove fold-const.c.
+	(gt-stmt.h, gt-fold-const.h, gt-input.h, gt-tree-ssa-ccp.h):
+	Remove rules.
+
+2004-12-18  Richard Henderson  <rth@redhat.com>
+
+	* stor-layout.c (layout_decl): Unshare size expressions copied
+	from the type.
+
+	* fold-const.c (multiple_of_p): Handle BIT_AND_EXPR when
+	BOTTOM is a power of two.
+
+2004-12-18  Richard Henderson  <rth@redhat.com>
+
+	* tree-nested.c (save_tmp_var): New.
+	(struct walk_stmt_info): Add is_lhs.
+	(walk_stmts) <MODIFY_EXPR>: Be more accurate with setting of
+	val_only; set is_lhs.
+	(convert_nonlocal_reference): Use save_tmp_var when is_lhs;
+	clear is_lhs when appropriate.
+	(convert_local_reference): Likewise.
+
 2004-12-18  Richard Earnshaw  <rearnsha@arm.com>
 
 	* arm/ieee754-sf.S (floatdisf): Fix label definition in FPA

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]