needless deep recursion in gt-c-decl.h

[Zack Weinberg]

On Mon, Aug 05, 2002 at 02:34:42PM -0700, Per Bothner wrote:
> 
> I.e. most of the recursion depth when marking *tree nodes*
> consists of marking *rtl modes*.  I'm suggesting that we don't
> need to mark rtl nodes while we're marking tree nodes.  Don't
> recurse into rtl from tree - we'll get to the rtl from the
> other roots anyway.  In that case your results suggest that a
> one-loop method is might work fine.

This creates a hidden assumption which may not actually be true: that
all RTL is reachable from the GC root set independent of pointers from
tree nodes.  I would rather eat a 5% speed hit than introduce a
potential bug of this form, which is likely to be extremely hard to
track down.  Note that we are discussing 5% of mark time, not 5% of
total runtime (mark time can dominate, so it's not to be ignored).

However.  There are not too many tree nodes that contain rtx fields -
all for which CST_OR_CONSTRUCTOR_CHECK succeeds; all for which
DECL_CHECK succeeds; and a few of EXPR nodes, SAVE_EXPR,
GOTO_SUBROUTINE_EXPR, RTL_EXPR, WITH_CLEANUP_EXPR, and
METHOD_CALL_EXPR.  I have been wondering off and on whether the RTL
fields should be ripped entirely out of the DECL and CST nodes,
replaced with a lookaside table of some sort.  This would give the
behavior you suggest as a convenient side effect.  Since, empirically,
those pointers are usually null (witness the benefits of making
DECL_RTL lazily constructed) it should not be a performance problem;
it may even improve performance by reducing the memory cost of CST and
DECL nodes.

To implement this, I would: Create a deletable hash table indexed by
address, which stores TREE_CST_RTL and DECL_RTL.  Modify the tree.h
accessor macros accordingly.  Modify the mark process so that when it
comes upon an object stored in a deletable hash table, it does not
recurse into that object; it simply marks the object and continues.
Then, in a second phase, it marks from all marked objects in all
deletable hash tables.  Unmarked objects in those tables are discarded
as usual.

Not sure what to do with the EXPR nodes that point to RTL, but they
may not be a significant problem.

What do you think?

zw