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

[Matt Austern <austern at apple dot com>]

On Wednesday, October 30, 2002, at 12:02 PM, Mark Mitchell wrote:

> --On Tuesday, October 29, 2002 12:37:05 PM -0800 Matt Austern 
> <austern@apple.com> wrote:
>
> > We've got a finish_file function in dp/decl2.c.  It walks the list of
> > global declarations, asking, for each one, whether it meets the
> > criteria for being output.  For some kinds of declarations, such
> > as inline functions, one of the criteria is whether the identifier
> > associated with that declaration has been referenced.
> FWIW, I've always thought that this feedback from the back end to the
> front end was a little weird.  I'd rather have the front end pass the
> back end the stuff it thinks might need to go out (perhaps having done
> some pruning of its own), and then let the back end pick among those
> things.  We have no infrastructure for that, though...
>
> > Second, any advice on where to put that callback?  There are two
> > obvious choices, assemble_name and a (not yet existant)
> > TREE_SET_SYMBOL_REFERENCED macro.
> I'd prefer the latter; there are fewer ways to mess that up.
>
> Bear in mind that the back end (unfortunately) only has a string; 
> you'll
> have to figure out how to map that back to the corresponding 
> FUNCTION_DECL,
> etc., in the front end.  I'm not sure that's easy.
I'm not sure it's easy either.  Unless I'm missing something, the 
mapping
from a mangled name back to a decl isn't stored anywhere.   In 
principle,
of course, for any identifier node id there should be at most one decl d
such that DECL_ASSEMBLER_NAME(d) == id.  How to find that decl is
another matter...

The easiest solution I've thought of is to set up a hash table on the 
side,
and, for the C++ front end only, change SET_DECL_ASSEMBLER_NAME
to add an entry to that table.

> A better, but more invasive, solution would be to keep the information
> about what tree the symbol corresponds to in the back end; it could use
> that information for other purposes as well.  (Like when the symbol
> corresponds to a constant global array, and the array index is a 
> constant,
> after optimization, and we want to just grab the constant out of the
> array.)
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.

			--Matt