On 14/06/2010 06:43, Ian Lance Taylor wrote:
David Brown<david.br...@hesbynett.no> writes:
After doing a bit more reading and thinking, it seems to me that
-fwhole-program will be used in most cases where LTO is used. You use
-flto when compiling each source file, then link them with gcc with
-flto and -fwhole-program. Except in the case of libraries or other
files which need external symbols, you will want that combination to
generate optimal code. So if this combination alone, without common
symbols, is going to cause problems, then this would be a much bigger
issue than if it is only triggered by common symbols.
That scenario is fine.
You can look back to see the problematic case posted earlier. It was
a case where one file was compiled with -flto, one file was compiled
without -flto, both files defined a common symbol with the same name,
the object files were linked together using -flto -fwhole-program, and
the gold plugin was not used. All elements are essential to recreate
the problem.
Ian
So as far as I understand it, the only problem with issuing accurate
warnings or errors is that at link-time you don't know if common symbols
have come from both LTO and non-LTO object files? Surely then the best
solution for now, erring on the side of caution, is to issue a warning
if the compiler/linker sees common symbols of any kind while -flto and
-fwhole-program are active but the gold plugin is not. This will, I
think, only affect a small number of cases (at least for C), and as more
systems start using gold, it will be even less of an issue.
A side-note of thanks:
LTO is a huge step forward for gcc. Someone else here posted that it
had reduced their program run-time by 2.75%. I believe it has a much
bigger potential than that - not necessarily because the resulting
programs will be smaller or faster, but because you no longer have to
compromise between structure and speed. As an embedded programmer,
speed and size are often critical - this means that gory implementation
details are often exposed in headers (to allow optimal inlining) rather
than being tucked away in implementation files. C++ programs should see
the benefits here immediately - their "setters" and "getters" can be
moved out of the headers entirely. Some of the other IPA and
cross-module optimisations introduced in gcc 4.5, such as re-arranging
function parameters (-fipa-sra) and interprocedural copy propagation,
mean that far more general libraries can be written. Consider something
as simple as a "setBaudRate(115200)" call. On an x86, calculating a
baud rate divisor here is just a few instructions. But on an 8-bit avr,
doing a 32-bit division is a long and large process. Typically the
embedded programmer will set the baud rate using a #define so that the
compiler can pre-calculate the divisor. With gcc 4.5, this will no
longer be necessary, and the setBaudRate function becomes independent of
the code that uses it. Wonderful!
For years embedded gcc fans have had to contend with claims of gcc being
old-fashioned, and inferior to the big-name commercial compilers. gcc
4.5 will go a long way to redressing that.
Many thanks to everyone who has worked on this (and the rest of gcc and
friends, of course). You might not have thought about embedded devices
like the ColdFire, ARM Cortex M3 and the like when you wrote this code.
You might not even have /heard/ of the 8-bit AVR or its gcc port. But
it is a testament to power of the gcc development model that these
"small" ports benefit from the hard work done here for the "big" targets.
David
