Unit at a time C++ again

[Jan Hubicka]

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

Hmm, I don't follow.  If C++ standard dicates what classes/functions are
instantiated and we do exactly that, how exactly do you propose to
change the current code?
> 
> > 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.

It looks like we are missunderstanding each other.

I do have everything available to the inliner since the first
incarnation of patch (this is the point of unit-at-a-time mode :)
- I do have code lowering pass that figure out what functions needs to
be expanded and output variables needed by these functions without
actually expanding the functions.  Once all functions are known I do
unit-at-a-time optimization.

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

I was reffering to the following code:
static void
output_vtable_inherit (tree vars)
{
  tree parent;
  rtx child_rtx, parent_rtx;

  child_rtx = XEXP (DECL_RTL (vars), 0);	  /* strip the mem ref  */

  parent = binfo_for_vtable (vars);

  if (parent == TYPE_BINFO (DECL_CONTEXT (vars)))
    parent_rtx = const0_rtx;
  else if (parent)
    {
      parent = get_vtbl_decl_for_binfo (TYPE_BINFO (BINFO_TYPE (parent)));
      parent_rtx = XEXP (DECL_RTL (parent), 0);  /* strip the mem ref  */
    }
  else
    abort ();

  assemble_vtable_inherit (child_rtx, parent_rtx);
}
That does bypass rest_of_decl_compilation.

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