[lto]: Patch to restructure file specific information.

[Jan Hubicka]

> Jan Hubicka wrote:
> >> i had seen them at the last summit.  Mark Mitchell had fantasized to me
> >> once about wanting a patch that would clean out all of the temporary
> >> information that the front ends produced right after gimplifying.   I
> >> think that such a patch should be strongly encouraged after we get rid
> >> of the lang hooks and other odds and ends like the front ends not
> >> gimplifiying the static initializers until late.
> >>
> >> However, with lto, that pie chart means nothing.  There, for large
> >> programs, there will be no front end garbage, it will all be function
> >> bodies and what is necessary to compile the function currently under the
> >> microscope.
> >>     
> >
> > I hope so, that is why I want to regenerate them.  The table mostly
> > suggested that type and symbol tables are places where a lot of memory
> > goes, but it might be because we hold around dead stuff that won't be
> > preserved across LTO if we are cureful.
> >
> > Just out of curiosity, do you know how much memory was needed for LTO
> > bootstrap and how does it compare with --combine?
> >
> > Honza
> >   
> >> kenny
> >>     
> we cannot bootstrap because of the problems listed on the wiki.  We are
> able to run the c spec marks becasee these contain no gcc extensions.  
> but we cannot lto the libraries.

Ah, i tought there was a point when LTO was bootstrapping but it is not
anymore.  Comparing memory footprint on any of bigger SPEC testcase
would be interesting too.  I will play a bit with this.

Honza
> 
> kenny