This is the mail archive of the
mailing list for the GCC project.
Re: GCC plugins & GGC & explicit gcc_free
- From: Trevor Saunders <tsaunders at mozilla dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail 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: Fri, 29 Aug 2014 20:13:46 -0400
- 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> <CABu31nNP2MfVyxDY90NhoDaX3cfq5miiXc5H9Nmvg2aYUQwyYA at mail dot gmail dot com>
On Sat, Aug 30, 2014 at 12:54:16AM +0200, Steven Bosscher wrote:
> On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders <email@example.com> 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.
I was thinking about http://gcc.gnu.org/ml/gcc/2014-07/msg00298.html
according to that we can't move symtab_node and friends, but maybe we
can move edges and basic blocks.
> 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.