Free more of CFG in release_function_body

Richard Biener rguenther@suse.de
Wed Nov 25 14:32:36 GMT 2020


On Wed, 25 Nov 2020, 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.

Possibly another case of a missing DECL_EXPR then.  In those cases
SSA names leak into TYPE_MIN/MAX_VALUE or TYPE/DECL_SIZE during
gimplification.  But those are frontend bugs (there are plenty reported).

Richard.


More information about the Gcc-patches mailing list