This is the mail archive of the
mailing list for the GCC project.
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 Guenther <email@example.com>
> 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.