From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-89579-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22332 invoked by alias); 20 Jan 2004 18:48:34 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 22323 invoked from network); 20 Jan 2004 18:48:33 -0000
Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23)
  by sources.redhat.com with SMTP; 20 Jan 2004 18:48:33 -0000
Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204])
	by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0KImWcb003650
	for <gcc@gcc.gnu.org>; Tue, 20 Jan 2004 10:48:32 -0800 (PST)
Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com
 (Content Technologies SMTPRS 4.3.6) with ESMTP id <T673f4e11b4118064cc748@mailgate2.apple.com>;
 Tue, 20 Jan 2004 10:48:32 -0800
Received: from [17.219.199.36] ([17.219.199.36])
	by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0KImVN7005823;
	Tue, 20 Jan 2004 18:48:32 GMT
In-Reply-To: <87u12qo5s2.fsf@egil.codesourcery.com>
References: <82D6F34E-4306-11D8-BDBD-000A95B1F520@apple.com> <20040110154129.GA28152@disaster.jaj.com> <C97CAA9B-452F-11D8-94EA-000A95B1F520@apple.com> <1073935323.3458.42.camel@minax.codesourcery.com> <F9B61B7C-4558-11D8-939E-0030657EA24A@apple.com> <1073951351.3458.162.camel@minax.codesourcery.com> <20040119013113.044D74895@quatramaran.ens.fr> <m3ad4kzp8o.fsf@uniton.integrable-solutions.net> <400BB40B.4070101@dsvr.net> <871xpvp9d7.fsf@egil.codesourcery.com> <20040120100839.GA21361@atrey.karlin.mff.cuni.cz> <87u12qo5s2.fsf@egil.codesourcery.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <3DF1B3B1-4B79-11D8-83EB-000A95B1F520@apple.com>
Content-Transfer-Encoding: 7bit
Cc: Nick Burrett <nick@dsvr.net>, gcc@gcc.gnu.org,
        Gabriel Dos Reis <gdr@integrable-solutions.net>,
        Marc Espie <espie@quatramaran.ens.fr>, Jan Hubicka <hubicka@ucw.cz>
From: Geoffrey Keating <geoffk@apple.com>
Subject: Re: gcc 3.5 integration branch proposal
Date: Tue, 20 Jan 2004 18:48:00 -0000
To: Zack Weinberg <zack@codesourcery.com>
X-SW-Source: 2004-01/txt/msg01534.txt.bz2


On 20/01/2004, at 10:04 AM, Zack Weinberg wrote:

> Jan Hubicka <hubicka@ucw.cz> writes:
>
>>> I am not sure why ggc_alloc comes in second; checking is disabled so
>>
>> My experience from oprofiling is, that ggc_alloc/garbage
>> collector/memset is where all our cache faults go, so they end up
>> high in profiles even when amount of work looks small.  It is not
>> really ggc_alloc fault, rather it is the fact that we use too much
>> of it.
>
> True.
>
> One cause of excessive memset that I have wanted to address for years
> is, make_node() clears the entire tree node - but make_node is almost
> always called from somewhere that's going to fill in most or all of
> the fields anyway.  We ought to have something like the gen_rtx_fmt_*
> functions for tree nodes.

You're looking at this the wrong way.  We have to load the object into 
cache anyway, it does not really matter if make_node does it or it's 
done later.

I'll emphasize Jan's comment: when you analyze GCC performance, you can 
usually disregard all code that doesn't cause cache faults.