From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22507 invoked by alias); 23 Apr 2011 21:33:10 -0000 Received: (qmail 22498 invoked by uid 22791); 23 Apr 2011 21:33:09 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 23 Apr 2011 21:32:53 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p3NLWouO024329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 23 Apr 2011 17:32:50 -0400 Received: from [127.0.0.1] (ovpn-113-57.phx2.redhat.com [10.3.113.57]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p3NLWnnL029786; Sat, 23 Apr 2011 17:32:49 -0400 Message-ID: <4DB34581.50704@redhat.com> Date: Sun, 24 Apr 2011 09:34:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Lawrence Crowl CC: reply@codereview.appspotmail.com, dnovillo@google.com, gcc-patches@gcc.gnu.org Subject: Re: [patch] Split Parse Timevar (issue4378056) References: <20110412184923.33F942225D6@jade.mtv.corp.google.com> <4DAF5782.90009@redhat.com> <4DB0CE6E.4080105@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg01941.txt.bz2 On 04/22/2011 06:41 PM, Lawrence Crowl wrote: > On 4/21/11, Jason Merrill wrote: >> On 04/21/2011 07:17 PM, Lawrence Crowl wrote: >> That makes sense. Inlines in the class aren't significantly different >> from inlines outside the class, but inlines are significantly different >> from non-inlines for our purposes. > > Do you have a quick hint for how to make that distinction? Check DECL_DECLARED_INLINE_P after we've parsed the declarator. >>>>> -DEFTIMEVAR (TV_TEMPLATE_INSTANTIATION, "template instantiation") >>>>> +DEFTIMEVAR (TV_INSTANTIATE_TEMPLATE , "instantiate template") >>>> >>>> Why these changes? >>> >>> Just to shorten the names. >> >> I'd prefer to keep it in the noun form. > > Okay. This on in particular was making the output wide. I wouldn't mind shortening it to TV_TEMPLATE_INST, I just object to the change from noun (instantiation) to verb (instantiate). >> The code is cleaner the way you have it, but not as correct, as there's >> some initialization being charged to parsing. > > Would you prefer moving that initialization out or placing the > start/stop into different routines? I think moving the initialization out would be better. Jason