This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [LTO] Move ChangeLog.lto into the GCC sub directory


Richard Guenther wrote:
> On Sat, 3 Jun 2006, Kenneth Zadeck wrote:
>
>   
>> Richard Guenther wrote:
>>     
>>> On Sat, 3 Jun 2006, Kenneth Zadeck wrote:
>>>       
>>>> The plan is to have the generation/insertion point be before the ipa
>>>> passes.  This way we can take advantage of all of that work.  
>>>>     
>>>>         
>>> Now my expectations for LTO were that we would have a (possibly reduced)
>>> set of local optimization passes including an early inlining phase run
>>> before the write-out for LTO;  IPA passes and "real" inlining at link
>>> time followed by another set of local optimization passes.
>>>
>>> This would make it possible to defer instrumentation for profile-based
>>> optimizations to before the LTO write-out and have a clean re-start
>>> for the profile-based transformations at the point of a profile directed
>>> link-time only optimization phase.
>>>
>>>   
>>>       
>> I do not see the benefit any profile directed optimization before the
>> lto writeout.  It seems that the right time to do that is when you have
>> everything in front of you that you are going to have and can make
>> truely global decisions. 
>>     
>
> Ah, no - I didn't say that.  The point I wanted to make is that
> the point of write-out/read-in is a suitable place to do the 
> instrumentation and the read of profile data.  So you would have
>
> -fprofile-generate: dump right before instrumentation and continue w/o LTO
> -fprofile-use: read the dumps for LTO and use the profile data to do 
>         profile based transformations (in the now LTO phase)
>
> this automatically gets you the same state for the instrumentation and
> the read of profile data.
>
> Does this make sense?
> Richard.
>
> --
> Richard Guenther <rguenther@suse.de>
> Novell / SUSE Labs
>   
I have never looked at the profile data but reading the profile data
should be something that could be done by the lto phase. I do not see
what advantage you gain by asking the files that are read in by the lto
phase to also contain their share of the profile data. 

Kenny


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]