On Fri, Aug 1, 2008 at 7:53 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:

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

Before free_lang_specifics was added, I dropped some of the tree while
streaming it out.  The advantage of this is that it doesn't trash the
FE-specfic info for the currently-running compilation, so that debug
info should be good for object code emitted during a -flto compile and
linked normally.

To move toward a language-independent IR, however, it is good hygiene
to strip this stuff so we aren't fooling ourselves.  When the lto IR
is streamed back in, lto1 will pick up the compilation more or less at
the point where it stood when the IR was written out, and proactively
cleaning the tree in free_lang_specifics will help us to anticipate
problems further along in the pipeline that might presently be masked
in our testing of lto1 by other streamer failures.

I agree that doing early name mangling at streamout time, only for the
declarations that are actually referenced and must be streamed out,
could be a huge win in the presence of large but sparsely-used header
files. I will try a few experiments here.  I'm not terribly
comfortable with aggressively cleaning the tree in free_lang_specifics
until we've clarified a GIMPLE type system and a plan for adjusting
early-generated debug info to reflect middle-end optimization.

--Bill

Reply via email to