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:
> 
> > 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
> branch!

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
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

Kenneth Zadeck


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