Statically-allocated objects with non-trivial ctors (was Re: [PATCH 33/35] Change use to type-based pool allocator in ira-color.c.)
Trevor Saunders
tbsaunde@tbsaunde.org
Fri May 29 05:16:00 GMT 2015
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
More information about the Gcc-patches
mailing list