Enable link-time optimization (after switching to avr-gcc 4.5 or greater) [imported]

[cmaglie]

This is Issue 660 moved from a Google Code project.
Added by 2011-09-27T22:38:57.000Z by ca...@strayorange.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Defect, Priority-Medium

Original description

avr-gcc 4.5 has support for LTO. Enabling it would probably allow sizable object size reductions, especially with -Os when linking libraries spanning multiple compilation units.

[matthijskooijman]

Here's a comment copied from Google Code:

LTO stands for link-time optimization and basically it means deferring most optimizations until all compilation units (each file being compiled, including libraries) have been processed.
As an example, consider a library function that's called only once in the current program. Without LTO both caller and callee will be compiled separately. With LTO the callee will be inlined (it's always profitable to inline a function that's called only once). While just inlining might look not much of a win, take into consideration that this also allows code specialization at compile-time.
For more information, look up the -flto and -fwhole-program compile options (http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options)

I've been looking at LTO and whole program optimization as well, since it greatly increases optimization opportunities for a templated I/O library I've been working on.

To get this working, -flto needs to be passed to all C/C++ compiler commands and linker commands. It seems sensible to pass -O0 to the compiler commands since optimization is done in the linker stage, but a quick test shows that this greatly increases resulting binary size, so I guess not all optimizations are run at link time and -Os must still be passed both when compiling and linking.

I've tested this here on avr-gcc 4.7 in Debian using Arduino-mk and it indeed helps to reduce code size (haven't looked closely at code speed yet).

However, for optimal LTO, gcc needs a "linker plugin", which doesn't seem to be available in my setup (not sure if this is a limitation of the AVR target and/or if this was / will be fixed in a more recent GCC version, thogh). AFAIU this linker plugin serves two purposes: It allows gcc to get LTO information out of archives (allowing the arduino core code in libcore.a to be included in the LTO process) and it allows gcc to know which functions are externally visible (in this case, only main()) so it can really tell if a function is used or not.

As an alternative for such a linker plugin, -fwhole-program can be passed to the linker. This flag tells gcc, "I've passed you all the code for this program and only main() and any functions with the externally_visible attribute are externally visible". However, since no linker plugin is used, any .o files compiled without -flto and any .a files included in the link are not included in the LTO and the optimizer will pretend they don't exist. In the Arduino case, the LTO will not see the actual main() function (which is in libcore.a) referencing setup() and loop(), making it remove the setup() and loop() functions (and probably all of the rest of your code as well). After LTO, the linker will then try to link your (now-empty) program with libcore.a and error out with "undefined symbol setup" and "undefined symbol loop".

Making -fwhole-program can be done by marking setup and loop as externally visible. e.g. put this in Arduino.h (or any other place included in the .ino file, just in main.cpp isn't enough):

void loop(void) __attribute__((externally_visible));
void setup(void) __attribute__((externally_visible));

Doing this makes the program a bit smaller and probably faster as well (it allows inlining and removing functions that are called in on place only, for example). However, it is probably a bit error prone to manually keep this list of externally visible functions, so I would advise only applying it if linker plugin support for AVR isn't going to happen soon and it turns out the optimization gain of -fwhole-program is significant.

[matthijskooijman]

It seems that since gcc 4.8, avr-gcc has the linker plugin working, meaning we can enable -flto and it should just work :-)

[cmaglie]

This may be enable after merging #1903 (just to keep a note inside the pull request).

[mikaelpatel]

The -flto option needs to be passed to the linker as well (compiler.c.elf). Below are the extra flags I am using for Cosa build (See https://github.com/mikaelpatel/Cosa/blob/master/platform.txt-gcc-4.8.1)

# These can be overridden in platform.local.txt
compiler.c.extra_flags=-Wextra -flto
compiler.c.elf.extra_flags=-w -flto
compiler.S.extra_flags=
compiler.cpp.extra_flags=-Wextra -flto
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=

This work nicely for the Cosa Arduino Framework. So far have all tests passed. Please note that some warnings from the link needs to suppressed (See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396)

Cheers! Mikael

[ffissore]

Current toolchain supports link time optimization, which is disabled by default. If you wish to use you can either modify platform.txt or provide your own custom core