This is the mail archive of the
mailing list for the GCC project.
Re: GCC plugins & GGC & explicit gcc_free
- From: Steven Bosscher <stevenb dot gcc at gmail dot com>
- To: Trevor Saunders <tsaunders at mozilla dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Basile Starynkevitch <basile at starynkevitch dot net>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Sat, 30 Aug 2014 00:54:16 +0200
- Subject: Re: GCC plugins & GGC & explicit gcc_free
- Authentication-results: sourceware.org; auth=none
- References: <1409326183 dot 8563 dot 7 dot camel at starynkevitch dot net> <ffa6d830-4a68-4c8c-a481-07aae8f6e4f6 at email dot android dot com> <20140829222338 dot GA30223 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com>
On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders <firstname.lastname@example.org> wrote:
>> Of course we should make things more explicit here and move all data structures out of GC that are explicitly freed. Work in that direction is welcome. The CFG is in GC memory because it indirectly refers to trees (the single most reason why things are in GC space, fixable nowadays with custom GC marker routines)
> I thought it was also because of pch?
That used to be true, but not anymore (ever since unit-at-a-time
became the default). The CFG is only constructed after the front end
is done writing a PCH.
The CFG could be put back into arenas or pools, if custom markers are
written and could be somehow called on objects that don't live in GGC
space themselves. Right now, our marking is really just a dumb
walk-everything approach, but it should be possible to use the
hierarchy we have, starting from symtab and marking top-down -
teaching custom markers to walk the CFG of a function body but to not
mark basic blocks, edges, and whatever else makes up the CFG.
> I'm hoping we'll soon be at a point where everything uses the overload
> based gc scheme currently used for user gc which should hopefully make
> custom marking easier, but pch will still be a big pain, and in fact is
> by far the worst part of implementing marking functions.
The first step really should be to simplify the marking for PCH
itself: Annotate structures for which we know they should never end up
in a PCH, and teach gengtype to just not write out marker functions
for them (just abort instead). Things that should never be seen in a
PCH: CFG basic blocks and edges, symtab nodes, GIMPLE, RTL (I think),
... If you teach gengtype to punt on those types, transitioning to
custom marking should be far easier.