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