This is the mail archive of the
mailing list for the GCC project.
Re: [LTO] Move ChangeLog.lto into the GCC sub directory
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>, gcc-patches at gcc dot gnu dot org, Steven Bosscher <stevenb dot gcc at gmail dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Sat, 03 Jun 2006 15:06:54 -0400
- Subject: Re: [LTO] Move ChangeLog.lto into the GCC sub directory
- References: <firstname.lastname@example.org> <Pine.LNX.email@example.com>
Richard Guenther wrote:
> On Sat, 3 Jun 2006, Kenneth Zadeck wrote:
>>> The next step will be to create the LTO "front end". At first, it will
>>> do nothing at all. Then, it will start reading declarative information
>>> out of object files. Then, the ordinary compiler will be changed to
>>> emit information for use at LTO. Then, the LTO front end will start
>>> reading the bodies of functions. Finally, there will be oodles of work
>>> to make it robust, support more programming languages, etc. I'm not
>>> sure there's anything that other people can usefully contribute here,
>>> yet -- but there will be once we get the skeleton in place, which will
>>> hopefully happen very soon.
>>> I don't think think the IPA branch work is likely to conflict, at least
>>> not any time soon. In general, LTO will just be using the same
>>> optimizers we already have; if those get smarter, LTO will get smarter
>>> too. The LTO branch will be primarily about reading/writing information
>>> and combining that information at link-time, not about improving the
>>> underlying optimizations.
>> 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.
> Richard Guenther <firstname.lastname@example.org>
> Novell / SUSE Labs