Re: Target FUNCTION_{PRO,EPI}LOGUE question

[Neil Booth <neil at daikokuya dot demon dot co dot uk>]

Fergus Henderson wrote:-

> But the name `public_flag' is only used in five lines of code
> (and one comment) in tree.h.  It isn't used anywhere else.

OK.  However, that was but a single example - there are many other
flags.  And look at all the helper macros that have misleading /
overloaded names.  The macros could be fixed, of course, since they
are macros, but I don't find it tasteful.

> But the tree_common struct only uses 2 pointers plus 32 bits for the
> tree_code and flags.  There's not a huge amount of bloat there.
> What you're proposing would add at least one pointer for the vtable,
> and the cost of that may well outweigh any gains you get from saving
> a pointer or two in certain node types.

Maybe.  Identifier nodes are a good example of current waste.

> > Another consequence is we get enormous switch statements switching on
> > a tree's TREE_CODE or TREE_CLASS.  I think most of those switch
> > statements should be replaced by virtual function calls.
> 
> I'm very skeptical about that.
> What would be the advantage?

It's a matter of taste, but I think it's hard to read and maintain.

> >    for (each root in all_ggc_roots)
> > 	root->vtable->gc_collect ();
> 
> (The virtual function should be called gc_mark() not gc_collect(), I think.)

You're right.

> I'm not convinced that this approach would be significantly more efficient.

I'd be surprised if it didn't give a 50% win - you've got single
instructions that go directly to the relevant code, in place of
function functions calls, comparisons and switch statements.  I've not
got any benchmarks, of course :-) Further, if you're garbage
collecting 50,000 items, say (I'm not sure of the number of items in
an average collection, but I imagine it's not far off this), I think
that hand-coded stack can get pretty big quite easily.

> The optimization of avoiding unnecessary checks for NULL_TREE is
> orthogonal, isn't it?

Yes.

> If you organize things by function, then adding a new type will require
> adding code everywhere.  If you organize things by data type, then
> adding a new function will require adding code everywhere.
> I think that for compilers in general and gcc in particular
> it is better to organize things by function rather than by
> data type, since adding a new compiler pass is a more common
> operation than adding a new kind of node to your abstract syntax tree.

True.  I firmly believe that the current way is less readable, less
efficient, and more error-prone.  Particularly now we're talking about
changing "tree" to make in front-end independent, and / or add another
layer of IR.

Neil.