Re: [lto] C++. streaming, front-end specific tree nodes, IR types, and assembler names

[Mark Mitchell <mark at codesourcery dot com>]

Diego Novillo wrote:

> > My assertion is that the langhook must go, and that mangled names
> > should be generated before invoking the middle-end.  Given the baroque
> > treatment of the assembler name, however, I don't think it will be
> > sufficient simply to make a pass over the declarations in
> > free_lang_specifics setting the assembler name.
> >
> > Any advice from someone who deeply understands this stuff?

That's certain the only choice if we're going to throw away DECL_CONTEXT 
(and lots of other information).  However, the reason that names are 
mangled lazily is that it was a significant compile-time performance 
improvement.  There are *tons* of functions in the typical C++ 
translation unit when you start #includ'ing big headers.  Typically, 
thought many of them reference one-another, only a few definitions are 
actually output.  They reference other functions whose definitions are 
not emitted, but not that many.  So, you'd like to avoid mangling all of 
them.

My concern is that the path we're heading towards is:

1. C++ front end generates all function bodies, including instantiating 
all templates that might be needed, mangles all names that might be 
needed, and precomputes all debug info that might be needed, and then 
hands the whole mess off to the gimplifier.

2. Middle-end builds call graphs, etc., and throws out 99.5% of the 
functions and debug info, after deciding it's not needed.  (Note, for 
example, that mangled names are typically not needed for inline functions.)

That's going to make -flto slow.  If we do it in a way that affects 
normal -O0 compilation, this would be a bad thing.  Maybe we should 
consider a strategy where the front-end data structures live until the 
point of LTO output, so that we can compute what we need at that point, 
based only on what we are going to output.  (And for DECL_COMDAT things, 
we should be outputting LTO information only if actually referenced.)

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713