Re: [lto]: Patch to restructure file specific information.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Jan Hubicka wrote:
>> 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
>>     
no, what it will do is compile all of the gcc i. files in isolation. 
the test for combining things was to make the c spec marks all work that
way.

kenny