From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114232 invoked by alias); 29 May 2015 02:04:13 -0000 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 Received: (qmail 114222 invoked by uid 89); 29 May 2015 02:04:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 May 2015 02:04:10 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [23.233.68.71]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id 4C4B3C07C; Fri, 29 May 2015 02:04:07 +0000 (UTC) Date: Fri, 29 May 2015 05:16:00 -0000 From: Trevor Saunders To: David Malcolm Cc: mliska , gcc-patches@gcc.gnu.org Subject: Re: Statically-allocated objects with non-trivial ctors (was Re: [PATCH 33/35] Change use to type-based pool allocator in ira-color.c.) Message-ID: <20150529020210.GA8578@tsaunders-iceball.corp.tor1.mozilla.com> References: <83d59ba92a3c4b3ba831ebc2fce325f0416848d0.1432735040.git.mliska@suse.cz> <27d56fd7847e4cf0f81b87885088235b564534e4.1432735040.git.mliska@suse.cz> <1432809777.12727.16.camel@surprise> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432809777.12727.16.camel@surprise> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg02716.txt.bz2 On Thu, May 28, 2015 at 06:42:57AM -0400, David Malcolm wrote: > On Wed, 2015-05-27 at 15:56 +0200, mliska wrote: > > gcc/ChangeLog: > > > > 2015-04-30 Martin Liska > > > > * ira-color.c (init_update_cost_records): Use new type-based pool allocator. > > (get_update_cost_record): Likewise. > > (free_update_cost_record_list): Likewise. > > (finish_update_cost_records): Likewise. > > (initiate_cost_update): Likewise. > > --- > > gcc/ira-color.c | 19 +++++-------------- > > 1 file changed, 5 insertions(+), 14 deletions(-) > > > > diff --git a/gcc/ira-color.c b/gcc/ira-color.c > > index 4750714..4aec98e 100644 > > --- a/gcc/ira-color.c > > +++ b/gcc/ira-color.c > > @@ -1166,16 +1166,8 @@ setup_profitable_hard_regs (void) > > allocnos. */ > > > > /* Pool for update cost records. */ > > -static alloc_pool update_cost_record_pool; > > - > > -/* Initiate update cost records. */ > > -static void > > -init_update_cost_records (void) > > -{ > > - update_cost_record_pool > > - = create_alloc_pool ("update cost records", > > - sizeof (struct update_cost_record), 100); > > -} > > +static pool_allocator update_cost_record_pool > > + ("update cost records", 100); > > Am I right in thinking that this is a statically-allocated object with a > non-trivial constructor? i.e. that this constructor has to run before > "main" is entered? yes though I think it'd be pretty easy to make it basically trivial but with a static initializer because gcc doesn't optimize them well, and with a bit more work we could probably get rid of the static initializer without actually fixing gcc. > Do our coding guidelines allow for this? (I've been burned by this > before, on a buggy C++ runtime that didn't manage to support these). I'm pretty sure there already are some iirc the pretty printers are one example. > I'm a little nervous about this, touching global state before > "main" (e.g. from the point-of-view of the JIT), though I don't know yet > if this is just a gut reaction, or if there's a valid concern here (I'm afaik it should work fine. Of course this is global data which isn't great, but that's a preexisting problem. Trev