Re: [PATCH 01/35] Introduce new type-based pool allocator.

[Jeff Law <law@redhat.com>]

On 05/29/2015 07:31 AM, Martin Liška wrote:
> On 05/28/2015 07:15 PM, Jeff Law wrote:
>> On 05/28/2015 06:49 AM, Martin Liška wrote:
>> .
>>>
>>> This mechanism has been just adapted. I find it quite useful as we have
>>> examples in source code where we
>>> allocate same struct/class types from a various pool. For debugging
>>> purpose, it helps to identify if
>>> release operation is called for a correct pool.
>> I saw that you were following existing practice for the pools in the
>> removal patch. I still don't like it as it makes mixing and matching
>> objects harder when debugging gcc and if the structure is exposed for
>> plugins, then we've got an unnecessary ABI plugin breakage.
>>
>> I certainly understand how it's useful -- I'm not questioning that.
>> I'm questioning changing the size of structures on ENABLE_CHECKING.
>>
>> My first inclination would be to include all that stuff
>> unconditionally.  If that's too much overhead, then perhaps include
>> the structure member, but not bother with any of the bookkeeping
>> except for ENABLE_CHECKING.
>
> Hi.
>
> Updated version of patch removes ENABLE_CHECKING in the struct definition.
>
> News in the patchset I'm going to re-send:
> + Changelog entries are fixed for spaces
> + Each patch passes ./contrib/check_GNU_style.sh script
> + pool_allocator::pool_allocator is a trivial constructor and first
> allocation launches initialization
> + some patches are squashed as were mentioned multiple time
> (ira-color.c, ira-build.c)
>
> The patch set survives x86_64-linux-pc boostrap, I'm going to re-run
> regression tests.
Sounds perfect.   Once the regression testing is done, the whole set is 
fine for the trunk.

Thanks for tackling this.

jeff