This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: GC allocating everything with a type, part 1
On Sunday 18 January 2004 05:36, Zack Weinberg wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> >> Would it not be appropriate to have separate type codes for every rtx
> >> and tree code?
I would have liked that, but it's much more work than what I'm aiming
for. I guess we can revisit this once RTL is back on obstacks, so we
only have to deal with one special case like this.
> > There are a few problems with doing that i can think of off the top of
> > my head that pretty much make it infeasible.
> >
> > 1. gengtype doesn't generate type codes like that, so we'd have to
> > make up a hackish way to include them in the gtype file by puttering
> > around in tree.def
>
> I don't see a quick way around this, you're right...
This is the biggest problem.
> > 2. This would require, among other things, large numbers of
> > modifications all over the place (because everything that uses
> > ggc_alloc_tree/rtx, including things that use it for a variety of
> > tree/rtl codes, would have to have some large switch.
>
> ... this isn't a problem; we just need a table mapping tree/rtx codes
> to type codes ...
I also considered using tree_size(), but it doesn't handle all cases
and it makes us less flexible wrt. creating highly customized tree
nodes (like we do for PHI nodes and SSA name on the tree-ssa branch).
> > 3. The only thing that these extra typecodes buy you is the ability to
> > segregate different types of trees into different places. Most trees
> > that are allocated around the same time should be close together in
> > memory, even if they are of different sizes.
> > That's why i moved trees into the tree zone, rather than trying to
> > further split up the tree zone.
>
> ... this isn't quite true ...
It would be true for the long-living trees if we would initially build
as much as possible in the garbage zone and then copy to the tree zone,
preferably as part of a collection step.
> > 4. The only immediate advantage to type coding everything to be able
> > to determine what marker routine to call on a given chunk of memory
> > (if we stop and restart marking, for example). You just need that
> > code i had discussed with you once that generates an array mapping
> > typecodes to marker routines (remember when i was trying to figure out
> > an easy way to make sure the marking routines that only existed in
> > some languages didn't get pulled into the common gtype-desc.h file,
> > where the arrays were going to be?)
> >
> > In this light, the tree marker knows how to mark all types of trees,
> > so we'd end up calling the same marking routine even if the type codes
> > were different anyway.
>
> ... consider how much simpler that tree marker would be if it didn't
> need to handle every last different kind of tree. Lots of small
> functions with straight-line code instead of one big one with a lot of
> conditionals. One of the things I'm interested in is clever logic to
> avoid recursion entirely in the marker.
Yup, some of the marker functions are just horrible. Honza has done
some benchmarking recently and gt_ggc_mx_lang_tree_node() is a
consistent "winner" in all profiles. To avoid recursion we should
also implement somethink to allow chain_next and chain_prev on more
than one field, this would help trees in some cases, and it would
also help in the cgraph markers.
But that's for another day.
Gr.
Steven