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 <Kenneth dot Zadeck at NaturalBridge dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: zadeck at naturalbridge dot com,Steven Bosscher <stevenb dot gcc at gmail dot com>,Andrew Pinski <pinskia at physics dot uc dot edu>,Richard Guenther <rguenther at charybdis-ext dot suse dot de>
- Date: Sat, 03 Jun 2006 14:43:51 -0400
- Subject: Re: [LTO] Move ChangeLog.lto into the GCC sub directory
- Reply-to: Kenneth dot Zadeck at NaturalBridge dot com
> Richard Guenther wrote:
> > While I think that placement of the ChangeLog file is not important
> > the important question whether LTO is a CodeSourcery internal project
> > is indeed popping up in this context. Can you share some of the immediate
> > plans you have for the branch with the rest of the community?
> Yes, I'd be happy to discuss that.
> As I said in my earlier announcement, the current committed participants
> are (in alphabetical order) CodeSourcery, IBM, NaturalBridge, and Red
> Hat. So, it's certainly not a "CodeSourcery internal project". (If we
> were trying to be secretive about it, we wouldn't do it on a public
You forgot to mention Google.
> CodeSourcery's not in charge of the project. We're contractually
> obligated to do some of the work, but we (and our client) certainly want
> the code to make it to mainline at some point (hopefully in 2007), which
> means the usual review processes, etc. CodeSourcery's particular area
> of responsibility is going to be reading/writing declarative
> information. We certainly hope that other people and organizations will
> particpate as well. There's a lot to do.
> The cleanups that Kazu has been working on are designed to reduce memory
> usage for trees, which we think is important since for LTO we'll want to
> process more functions as part of a single translation unit. So, in
> some sense, this work is orthogonal to LTO itself -- but it's also part
> of making LTO practical. Those changes will also benefit non-LTO
> compilation. Certainly, any other memory-reduction cleanups would be
> appropriate for the LTO branch, no matter who writes them.
> 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.
> Mark Mitchell
> (650) 331-3385 x713