This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Statically-allocated objects with non-trivial ctors (was Re: [PATCH 33/35] Change use to type-based pool allocator in ira-color.c.)


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  <mliska@suse.cz>
> > 
> > 	* 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> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]