This is the mail archive of the gcc@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: Issue with LTO/-fwhole-program


On 14/06/2010 06:43, Ian Lance Taylor wrote:
David Brown<david.brown@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



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