[RFA][PATCH] Adding missing calls to bitmap_clear

Richard Biener richard.guenther@gmail.com
Tue Mar 22 10:22:00 GMT 2016


On Mon, Mar 21, 2016 at 9:32 PM, Jeff Law <law@redhat.com> wrote:
> On 03/21/2016 01:10 PM, Bernd Schmidt wrote:
>>
>> On 03/21/2016 08:06 PM, Jeff Law wrote:
>>>
>>>
>>> As noted last week, find_removable_extensions initializes several
>>> bitmaps, but doesn't clear them.
>>>
>>> This is not strictly a leak as the GC system should find dead data, but
>>> it's better to go ahead and clear the bitmaps.  That releases the
>>> elements back to the cache and presumably makes things easier for the GC
>>> system as well.
>>>
>>> Bootstrapped and regression tested on x86_64-linux-gnu.
>>>
>>> OK for the trunk?
>>
>>
>> Looks like they don't leak anywhere, so ok. Probably ok even to install
>> it now but maybe stage1 would be better timing.
>
> I don't mind waiting for the next stage1, this is a pretty minor issue.

It's ok at this stage as it will also fix -fmem-report.  Please also move
the thing back to heap, see below.

Btw we should disallow bitmap_initialize (&x, NULL) as it does not do
the same thing as BITMAP_ALLOC (NULL), it does the same thing
as BITMAP_ALLOC_GC ().  Thus I'd rather have a bitmap_initialize_gc (&x)
and a bitmap_initialize (&x, NULL) that ends up using the global
bitmap obstack.  No idea where REE came from history wise.

A grep shows only

ira.c:  bitmap_initialize (&seen_insns, NULL);
ree.c:  bitmap_initialize (&init, NULL);
ree.c:  bitmap_initialize (&kill, NULL);
ree.c:  bitmap_initialize (&gen, NULL);
ree.c:  bitmap_initialize (&tmp, NULL);

btw, so please consider simply changing bitmap_initialize behavior.  The IRA
use also should use the global bitmap obstack as users around that use
use BITMAP_ALLOC (NULL).  [use a default arg for 'obstack' if possible,
you have to verify it works with/without --enable-gather-detailed-mem-stats]

Thanks,
Richard.

> jeff



More information about the Gcc-patches mailing list