Re: Unit at a time C++ again

[Mark Mitchell <mark at codesourcery dot com>]

On Thu, 2003-06-19 at 01:47, Jan Hubicka wrote:
> Hi,
> > > OK, dealing with template instantiation should not be too dificult (I
> > > think I can simply instantiate all templates with the code I am having
> > > right now).  Dealing with at least needed portion of the datastructures
> > > should not be impossible, but I would like first to understand what
> > > exactly it does buy to us...
> > 
> > The template instantiation part of the issue is pretty clear: in big C++
> > programs many (if not most) of the functions are template
> > instantiations.  Trying to make decisions before template instantiation
> > is not worth it.
> 
> This is what I am partly affraid of - forcing all instantiations to
> actually happen (and not only doing the reachable ones) seems to be
> problem as we produce a lot of unneeded trees.

You don't have a choice in the matter. :-)

The C++ standard says which classes/functions are instantiated based on
a particular input program, and our template instantiation model
dictates that you instantiate all of the needed ones in every
translation unit that needs them.

> Yes, this is clear to me, however what I don't understand why you
> consider the split scheme where reachable datastructures are produced by
> frontend and reachable functions maintained by backend major problem.

Because in order to make good heuristic decisions about inlining you
really want *everything* available to the inliner.

Furthermore, I want to avoid one of Zack's "incomplete transitions." 
There's a need to develop code incrementally, but there's no reason we
should adopt it in the compiler incrementally.  It would be better if
you would do this work on a branch, make it work, and check in the
branch.
 
> I am now working on adding variable graph companion to my callgraph code
> (for C/objC this seems to be pretty easy).  This will hopefully get the
> code closer to what we are shooting for.  For C++ there seems to be
> problem with virtual tables as these are not output only via
> assemble_variable and do have dependencies in between middle end does
> not see.

I don't see any calls to assemble_variable in the C++ front end. 
AFAICT, the vtables are emitted via rest_of_decl_compilation like other
variables.  If that's not true, it should be fixed.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com