From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11470 invoked by alias); 22 Jan 2004 17:00:52 -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 11419 invoked from network); 22 Jan 2004 17:00:49 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sources.redhat.com with SMTP; 22 Jan 2004 17:00:49 -0000 Received: (qmail 10288 invoked from network); 22 Jan 2004 17:00:38 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO codesourcery.com) (mitchell@66.60.148.227) by mail.codesourcery.com with SMTP; 22 Jan 2004 17:00:38 -0000 Message-ID: <401001B1.7080506@codesourcery.com> Date: Thu, 22 Jan 2004 17:02:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Jan Hubicka CC: Richard Guenther , gcc@gcc.gnu.org Subject: Re: RFC: cache uses_template_parms in tree node? References: <400FF7C4.50003@codesourcery.com> <20040122165810.GD8219@atrey.karlin.mff.cuni.cz> In-Reply-To: <20040122165810.GD8219@atrey.karlin.mff.cuni.cz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-01/txt/msg01771.txt.bz2 Jan Hubicka wrote: >>Richard Guenther wrote: >> >> >>>Hi! >>> >>>To address the for_each_template_parm() performance problem, would it be >>>possible to cache the outcome of uses_template_parms() in the tree >>>node? Or would this caching somehow be invalidated later? >> >>The right approach, as I've said before, is simply not to *use* >>for_each_template_parm. >> >>It should be unncessary; the right approach should be to use >>type_dependent_p and its friends. >> >>That's not a trivial change, but it's the right change. > > > Mark, > do you think such a change is possible for 3.4 GCC? If not what would > you recommend to do for the release branch? The for_each_template_parm > seems to be really one of the major CPU cycle consumers when it come to > C++ compilation and it would be shame to leave it that way for the > release. I'm looking into it as we speak. -- Mark Mitchell CodeSourcery, LLC mark@codesourcery.com