Implementing unit-at-a-time for C++

[Jan Hubicka <jh at suse dot cz>]

> 
> 
> --On Friday, February 28, 2003 08:35:52 PM -0800 Devang Patel 
> <dpatel at apple dot com> wrote:
> 
> >
> >On Friday, February 28, 2003, at 06:05 PM, Richard Henderson wrote:
> >
> >>On Fri, Feb 28, 2003 at 05:41:24PM -0800, Mark Mitchell wrote:
> >>>Instead, why not apply the same logic to the TYPE nodes themselves,
> >>>and
> >>>set DECL_IGNORED?
> >>
> >>Do we even have this information available?  I don't think
> >>we do.  The VAR_DECL nodes from automatic variables should
> >>be gone by this time.
> >>
> >>We could perhaps have started out with some sort of mark
> >>on TYPE nodes, which starts unset, and is set only when
> >>some DECL that makes it to debug info makes use of it.
> >>This, however, would be a rather large change, I think.
> 
> Yes, but this is the right thing to do.  In fact, what we should do is, at 
> the end of the translation unit, go through and discard all trees that we 
> won't need, and show the back end only those trees that are needed.
> 
> Until that point, absolutely no RTL should be generated, and nothing should 
> be written to the assembly file.
> 
> If you ask me, of course. :-)

:)
In the unit-at-a-time mode in C/objC we already follow this scheme.  I
would really love to get the C++ frotend to work using it as well.
What I need for that is to make C++ frotend to realize what functions
will be referenced from virtual method tables after expanding given
function before it is expanded  (so all needed templates can be
instantiated and callgraph built before we start spitting out any RTL at
all).

Currently C++ frontend does it in (at least at first glance) quite
complex way in finish_file that actually depends on the data being
assembled to get DECL_NEEDED_P set.  Any idea how much work would be
needed to get this working in the new way?

Honza
> 
> I'm OK with the patch because it's very expedient: it's a win, and it's 
> pretty self-contained, and the other solution is definitely more work.
> 
> -- 
> Mark Mitchell                mark at codesourcery dot com
> CodeSourcery, LLC            http://www.codesourcery.com