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
Daniel Berlin <dberlin@dberlin.org> writes:
>> Would it not be appropriate to have separate type codes for every rtx
>> and tree code?
>
> 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...
> 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 ...
> 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 ...
> 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.
zw