This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC plugins & GGC & explicit gcc_free

On Sat, Aug 30, 2014 at 12:54:16AM +0200, Steven Bosscher wrote:
> On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders <> 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
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.
> Ciao!
> Steven

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]