On Mon, Jun 14, 2010 at 9:26 AM, David Brown <da...@westcontrol.com> wrote: > 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.
Well, commons are only one issue - you also have the issue that for functions GCC thinks are not referenced from outside it will change the ABI of that function as it suits. Which will also give interesting errors if you still reference that from outside. So there is really no way around getting accurate symbol resolution information if you want to make -fwhole-program work in all cases (that it was not designed for). But then we wouldn't need -fwhole-program at all but could just automagically bring symbols local. Thus - -fwhole-program was exactly designed to give GCC information about symbols _it can't get access to otherwise_. And it has (or should have) a big warning in its documentation. Richard. > > 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 > > >
