Issue with LTO/-fwhole-program

[David Brown]

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