This is the mail archive of the 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

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.

Mark Mitchell
(650) 331-3385 x713

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