From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21308 invoked by alias); 4 Sep 2002 23:04:17 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 21301 invoked from network); 4 Sep 2002 23:04:16 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 4 Sep 2002 23:04:16 -0000 Received: from www.dberlin.org (pool-138-88-3-69.res.east.verizon.net [138.88.3.69]) by mail.cdt.org (Postfix) with ESMTP id AC73849004C; Wed, 4 Sep 2002 18:42:48 -0400 (EDT) Received: by www.dberlin.org (Postfix, from userid 503) id 0030D1815DC0; Wed, 4 Sep 2002 19:04:47 -0400 (EDT) Received: from dberlin2.local. (unknown [192.168.0.252]) by www.dberlin.org (Postfix) with ESMTP id 7682A1814EF7; Wed, 4 Sep 2002 19:04:46 -0400 (EDT) Date: Wed, 04 Sep 2002 16:04:00 -0000 Subject: Re: TREE_CODE mania Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: gcc@gcc.gnu.org To: Devang Patel From: Daniel Berlin In-Reply-To: <849C4B5D-C02A-11D6-9FC4-00039362EF82@apple.com> Message-Id: Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01,USER_AGENT_APPLEMAIL version=2.40-cvs X-Spam-Level: X-SW-Source: 2002-09/txt/msg00155.txt.bz2 On Wednesday, September 4, 2002, at 01:19 PM, Devang Patel wrote: > > On Tuesday, September 3, 2002, at 08:51 PM, Daniel Berlin wrote: > >> On Tue, 3 Sep 2002, Devang Patel wrote: >> >>> Hi All, >>> >>> Recently there was a discussion about faster compile time. And >>> memory usage and/or allocation is considered one probable >>> culprit behind the slow compiler. >>> >>> To understand actual memory usage pattern, I instrumented GCC >>> by replacing TREE_CODE macro with function TREE_CODE_read(). >>> I just wanted to see what is the usage pattern and how bad/good is >>> it. >>> >>> I collected profiled data for following one line program. >>> >>> int foo() { return 1;} >>> >>> Now, gprof tells me that to compile this, cc1 calls TREE_CODE_read() >>> 37572 times! I was expecting that number to be in couple of thousands >>> range but 37k seems high to me. >>> >>> I think, such a high number of indirect memory references puts >>> high pressure on VM and GCC's memory manager to maintain locality. >> >> Which it doesn't. >> Can't we attack this problem directly? >> By maybe using object based bins rather than size based ones, at >> least for >> trees and RTL? > > Sure, we can try using different allocation schemes to achieve better > compile > time performance. But this approach is like -- earn more money and > allocate > funds in better way to meet the budget. I am thinking in terms, can we > reduce > expenditure ? By the by, did you mark the TREE_CODE_read function as const/pure (i'm not sure tree_code's aren't modified in place, if they are, it's both, if they aren't, it's at least one of them), so that it accurately simulates the macro in terms of actual accesses? > I think, we need to work in both direction to achieve better > compile time speedup. > > -Devang