This is the mail archive of the
mailing list for the GCC project.
Re: [LTO] Move ChangeLog.lto into the GCC sub directory
- From: Richard Guenther <rguenther at suse dot de>
- To: Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>
- Cc: gcc-patches at gcc dot gnu dot org, zadeck at naturalbridge dot com, Steven Bosscher <stevenb dot gcc at gmail dot com>, Andrew Pinski <pinskia at physics dot uc dot edu>
- Date: Sat, 3 Jun 2006 21:02:21 +0200 (CEST)
- Subject: Re: [LTO] Move ChangeLog.lto into the GCC sub directory
- References: <firstname.lastname@example.org>
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.
Richard Guenther <email@example.com>
Novell / SUSE Labs