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

[Mark Mitchell <mark at codesourcery dot com>]

> 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...
Right.

> 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.
That will probably work, but will cost memory of course.

> > 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.
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.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com