Re: [C++ patch] Re: Free more of CFG in release_function_body

[Jeff Law <law@redhat.com>]

On 11/27/20 6:26 AM, Jan Hubicka wrote:
>>> On Wed, Nov 25, 2020 at 3:11 PM Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>> On Tue, 24 Nov 2020, Jan Hubicka wrote:
>>>>>
>>>>>> Hi,
>>>>>> at the end of processing function body we loop over basic blocks and
>>>>>> free all edges while we do not free the rest.  I think this is leftover
>>>>>> from time eges was not garbage collected and we was not using ggc_free.
>>>>>> It makes more sense to free all associated structures (which is
>>>>>> importnat for WPA memory footprint).
>>>>>>
>>>>>> Bootstrapped/regtested x86_64-linux, OK?
>>>>> OK.
>>>> Unforutnately the patch does not surive LTO bootstrap.  The problem is
>>>> that we keep DECL_INITIAL that points to blocks and blocks points to
>>>> var_decls and these points to SSA_NAMES that points to statements and
>>>> those points to basic blocks.
>>> VAR_DECLs point to SSA_NAMEs?  It's the other way around.  We for sure
>>> free SSA_NAMEs (well, maybe not explicitely with ggc_free).
>> I am going to debug this more carefully now.  I think it was VAR_DECL
>> with variadic type pointing to SSA_NAME.  Should be easy to reduct with
>> gcac compiler.
> Hi,
> it turns out that the pointers to statements leaks through saved scopes
> in C++ FE.  Scopes seems to point to internal blocks of functions even
> after we finish their compiling.
>
> This patch adds code to free pointers.  I tried to clear saved_blocks
> but it breaks since C++ finalization uses them, but it does not look
> into previous class levels.
>
> Patch lto-bootstraps/regtestes x86_64-linux with all languages. OK?
>
> Honza
>
> 	* cfg.c (free_block): Call ggc_free on BB itself.
I'll ACK this bit.  The C++ team should own the rest, while it looks
reasonable to me, there may be some reason I'm not aware of that they're
keeping that stuff around.

Jeff