Re: Improved use of TREE_SYMBOL_REFERENCED in the C++ front end

[Matt Austern <austern at apple dot com>]

On Thursday, October 31, 2002, at 10:03 AM, Mark Mitchell wrote:

> > More invasive, indeed!  You're probably right that it would be better,
> > though.  If you can persuade me that this wouldn't be quite as ghastly
> > as it looks like it would be, though, I'll go for it.  As you say, it
> > could well be useful for other reasons anyway.
> I don't think it would be extraordinarily horrible.
>
> You just need to find the places we call assemble_name and pass in a
> DECL, when there is one to be had.  What that really means, is finding
> the places where SYMBOL_REFs are created and pass in a DECL, where
> appropriate.  This is one of those things that will end up being a big,
> but largely mechanical, patch.  You don't have to set the DECL field
> in the SYMBOL_REF everywher possible -- just everywhere that you need
> the call back to occur.  That may just be make_decl_rtl.
OK, I'll look.  If I can avoid wasting memory, that would obviously
be A Good Thing.  (Speaking of avoiding memory wastage, one
alternative I didn't mention was sticking a backreference to the
decl in one of the identifier slots that's currently unused for
mangled names.  Main reason I didn't mention it is that some
other people at Apple are looking at drastically reducing the
space required to store mangled names.  It's silly to cart around
a huge data structure that you only use one word of.)

Oh, and also speaking of big but mechanical patches...

Something I didn't mention in my previous message is that if
we're going to put a callback in the macro that sets the
referenced bit, the first step is to create that macro!  That is,
the first step is to (1) change TREE_SYMBOL_REFERENCED
so that it returns an rvalue; (2) create a new macro,
TREE_SET_SYMBOL_REFERENCED; and (3) change every
place in the compiler that uses TREE_SYMBOL_REFERENCED
in an lvaluish way so that it uses the new SET macro instead.

I'm tempted to submit this patch first, before doing anything
else, just so that this sort of bookkeeping change doesn't get
confused with the real work later on.  It'll touch code all over the
compiler, but the changes are all trivial.  And my understanding
is that this sort of change is considered to be a good idea on its
own merits, since we're gradually working toward getting rid of
the lvalue-returning macros.

Sound reasonable to you?  If so, where would be the best place
to submit that patch?  I could argue for either TOT or the basic
improvements branch.

			--Matt