From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2233 invoked by alias); 21 Feb 2009 12:50:56 -0000 Received: (qmail 2196 invoked by alias); 21 Feb 2009 12:50:42 -0000 Date: Sat, 21 Feb 2009 12:50:00 -0000 Message-ID: <20090221125042.2195.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg01853.txt.bz2 ------- Comment #41 from rguenther at suse dot de 2009-02-21 12:50 ------- Subject: Re: [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays On Sat, 21 Feb 2009, hubicka at gcc dot gnu dot org wrote: > ------- Comment #40 from hubicka at gcc dot gnu dot org 2009-02-21 12:40 ------- > I happen to have compiler with statistics around: > We still need about 400MB, mostly integer constants: > c-decl.c:473 (bind) 125040: 0.0% 0: > 0.0% 0: 0.0% 0: 0.0% 2605 > tree.c:5905 (build_function_type) 13000: 0.0% 0: > 0.0% 113400: 0.1% 5056: 0.0% 632 > stringpool.c:73 (alloc_node) 6032: 0.0% 0: > 0.0% 174096: 0.1% 13856: 0.0% 1732 > langhooks.c:543 (add_builtin_function_common) 0: 0.0% 0: > 0.0% 442224: 0.2% 59760: 0.2% 1494 > c-typeck.c:6472 (output_init_element) 0: 0.0% > 47910400:100.0% 45541112:23.7% 26342936:66.6% 19 > convert.c:752 (convert_to_integer) 117415728:44.6% 0: > 0.0% 0: 0.0% 13046192:33.0% 1630774 > ggc-common.c:187 (ggc_calloc) 67094608:25.5% 0: > 0.0% 67162736:34.9% 1088: 0.0% 58 > tree.c:1004 (build_int_cst_wide) 78264768:29.8% 0: > 0.0% 78266496:40.7% 0: 0.0% 3261068 > Total 262986355 47910416 > 192171521 39527780 4905807 > source location Garbage Freed > Leak Overhead Times > > > It seems that we produce awful amount of garbage during the initializer > construction. Perhaps by forcing ggc_collect there we can get down to 200MB > that we need to reprezent it at the end? We need the integer csts in the constructor lists. I have a patch somewhere (or is it even attached?) that tries to do index compression and not use the integer csts for counting. Didn't work out too much though. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245