This is the mail archive of the
mailing list for the GCC project.
Re: RFA: Fix other/44566
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Andi Kleen <andi at firstfloor dot org>, ian at airs dot com
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Joern Rennecke <amylaar at spamcop dot net>, Mark Mitchell <mark at codesourcery dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Steven Bosscher <stevenb dot gcc at gmail dot com>, gcc-patches at gcc dot gnu dot org
- Date: Thu, 1 Jul 2010 12:03:35 +0200
- Subject: Re: RFA: Fix other/44566
- References: <Pine.LNX.firstname.lastname@example.org> <email@example.com> <Pine.LNX.firstname.lastname@example.org> <email@example.com> <Pine.LNX.firstname.lastname@example.org> <email@example.com> <4C27D2EB.firstname.lastname@example.org> <email@example.com> <20100627233650.GE21666@atrey.karlin.mff.cuni.cz> <firstname.lastname@example.org>
> Jan Hubicka <email@example.com> writes:
> > I've setup WHOPR bootstrap and I use it daily. It is sort of in useable stage.
> > Main observation is that we build backend _really_ many times. Our LTO
> > code is still doing one build to produce .o and then compile again, so it
> > is automatically about twice sloer.
> I also noticed that LTO always compiles twice for other projects. I
> understand this is needed for compatibility with old Makefiles that do
> not invoke the linking step correctly. But it still seems like quite a
> waste for updated Makefiles. Would it be possible to turn the first code
> generation step off and only rely on the link to code generation?
Yes, this is something I would like to see changed (probably for default,
I think users rarely will really use the fat object files). The major
problem here is how linker works - it links based on symbols used/exported
by the object files and then it calls plugin. So if you only output the
bytecode, it will not link anything.
We need to discuss how to deal with this. It is not even correct, since optimized
code in .o and one produced by LTO might be different and might need different
symbols. When the second code will use more symbols, linking fails.
I can just walk callgraph/varpool and references and output empty symbol
definitions and array of useses on what the program needs at time it is streamed
out, but that will result in .o files that when linked normal way would produce
> firstname.lastname@example.org -- Speaking for myself only.