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
Thu May 28 20:42:00 GMT 2015
On Thu, May 28, 2015 at 08:47:16PM +0200, Martin Liška wrote:
> On 05/28/2015 08:03 PM, Jakub Jelinek wrote:
> >On Thu, May 28, 2015 at 07:57:39PM +0200, Richard Biener wrote:
> >>But we've been trying to avoid this. And the jit might not be too happy about it either.
> >
> >Yeah, we should certainly try to avoid them, especially if it would affect
> >many variables having to be constructed.
> >
> > Jakub
> >
>
> Ok, thus I will do it as before my modifications:
>
> static pool_allocator <update_cost_record> *update_cost_record_pool = NULL;
>
> /* Initiate update cost records. */
> static void
> init_update_cost_records (void)
> {
> update_cost_record_pool = new pool_allocator <update_cost_record>
> ("update cost records", 100);
> }
>
> I'm going to migrate rest of patches that use the same construct.
Hrm, why not just change pool_allocator so it does the first allocation
on the first alloc and just initializes everything to null / 0? Then
the ctor would be close to trivial. Then if you really care about the
stuff gcc doesn't optimize away you could add a special class
static_pool_allocator (you might also need to hack in a way to get the
c++ fe to do constexpr / defaulted functions).
Trev
>
> Thanks,
> Martin
>
More information about the Gcc-patches
mailing list