From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8448 invoked by alias); 20 Dec 2007 15:31:21 -0000 Received: (qmail 8390 invoked by alias); 20 Dec 2007 15:31:07 -0000 Date: Thu, 20 Dec 2007 15:31:00 -0000 Message-ID: <20071220153107.8389.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/26854] Inordinate compile times on large routines In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "zadeck at naturalbridge dot com" 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: 2007-12/txt/msg01907.txt.bz2 ------- Comment #45 from zadeck at naturalbridge dot com 2007-12-20 15:31 ------- Subject: Re: Inordinate compile times on large routines stevenb dot gcc at gmail dot com wrote: > ------- Comment #44 from stevenb dot gcc at gmail dot com 2007-12-20 15:08 ------- > Subject: Re: Inordinate compile times on large routines > > On 20 Dec 2007 14:49:12 -0000, zadeck at naturalbridge dot com > wrote: > >> ------- Comment #43 from zadeck at naturalbridge dot com 2007-12-20 14:49 ------- >> Subject: Re: Inordinate compile times on large >> routines >> >> lucier at math dot purdue dot edu wrote: >> >>> ------- Comment #42 from lucier at math dot purdue dot edu 2007-12-20 03:52 ------- >>> Created an attachment (id=14799) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view) >>> > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view) > >> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view) >> >>> --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14799&action=view) >>> memory details for an unpatched mainline >>> >>> Here is the same information without Steven's two patches for mainline. >>> >>> >>> >>> >> Could you add the attached patch in and rerun your example? >> >> It will add 4 lines to indicate what kinds of def-use and use-def chains >> are being created. >> A lot of the space is being used by these chains and I want to find out >> how many of those chains are for artificial uses and defs. >> >> thanks >> >> kenny >> struct df_link * >> df_chain_create (struct df_ref *src, struct df_ref *dst) >> { >> struct df_link *head = DF_REF_CHAIN (src); >> - struct df_link *link = pool_alloc (df_chain->block_pool);; >> + struct df_link *link = pool_alloc (df_chain->block_pool); >> + int index = 0; >> + >> + if (!src->insn) >> + index += (src->type == DF_REF_REG_DEF) ? 2 : 1; >> + if (!dst->insn) >> + index += (src->type == DF_REF_REG_DEF) ? 2 : 1; >> + >> + df_chain_counters[index]++; >> > > Watch for segfaults. Index will be 1, 2, 3, or 4. > df_chain_counters[4] does not exist. > > > indexes will be 0, 1, 2, 3. there are no def-def chains, and in particular there are no artificial def to artificial def chains. those increments only happen for artificial defs or uses. Regular uses or defs have an insn. a normal def-use chain will have index 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854