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