Link Time Optimization
Link Time Optimization (LTO) is a program memory usage optimization mechanism that the compiler performs at link time. At compile time, the compiler creates a special intermediate representation of all translation units. It then optimizes them as a single unit at link time, which uses less memory than non-LTO builds.
Using LTO in Mbed OS
The Mbed OS build system implements LTO as an optional profile extension in tools\profiles\extensions\lto.json
. Enabling LTO amends the build profile with LTO flags.
Note: LTO performs heavy memory optimizations that break debugging, so we recommend using it only with the release profile, not debugging and develop.
To enable LTO, add the --profile
option with the LTO file path tools\profiles\extensions\lto.json
to the build command.
Note: For profile extensions you have to put the full path relative to the project's root folder.
To enable LTO with the release
profile:
mbed compile -t TOOLCHAIN -m TARGET --profile release --profile mbed-os/tools/profiles/extensions/lto.json
Example LTO profile memory savings for mbed-os-example-blinky:
Build type | Total static RAM memory (data + BSS) | Total flash memory (text + data) |
---|---|---|
GCC_ARM - release - no LTO | 12,096B | 44,628B |
GCC_ARM - release - LTO | 11,800B | 41,088B |
saved memory | 296B | 3,540B |
ARM - release - no LTO | 10,365B | 35,496B |
ARM - release - LTO | 10,153B | 31,514B |
saved memory | 212B | 3,982B |
LTO profile build results for mbed-cloud-client-example:
Build type | Total static RAM memory (data + BSS) | Total flash memory (text + data) |
---|---|---|
GCC_ARM - release - no LTO | 59,760B | 389,637B |
GCC_ARM - release - LTO | 59,432B | 354,167B |
saved memory | 328B | 35,470B |
ARM - release - no LTO | 58,099B | 353,849B |
ARM - release - LTO | 57,150B | 322,500B |
saved memory | 949B | 31,349B |
Limitations
- LTO slows down the build process.
- It’s very hard to control memory placement when using LTO.
- LTO performs heavy memory optimizations that break debugging.
- In LTO builds, the compiler produces bytecode/bitcode instead of regular object code. It's hard to analyze this output with object code analysis tools.
- LTO could cause increases to the stack space needed due to cross-object inlining.
Arm Compiler 6
- No bitcode libraries:
armlink
only supports bitcode objects on the command line. It does not support bitcode objects coming from libraries.armlink
gives an error message if it encounters a file containing bitcode while loading from a library. - Partial Linking is not supported with LTO as it only works with ELF objects not bitcode files.
- Arm recommends that link time optimization is only performed on code and data that does not require precise placement in the scatter file, with general input section selectors such as
*(+RO)
and.ANY(+RO)
used to select sections generated by link time optimization. It is not possible to match bitcode in.llvmbc
sections by name in a scatter file. - Bitcode objects are not guaranteed to be compatible across compiler versions. This means that you should ensure all your bitcode files are built using the same version of the compiler when linking with LTO.
GCC_ARM
- The minimal required version of
GCC_ARM
is the GNU Arm Embedded Toolchain Version 9-2019-q4-major. EarlierGCC_ARM
versions can cause various issues when the-flto
flag is used, for example a platform-specific error during the final link stage on Windows hosts with GCC8. - You must use the
noinline
attribute for every function that must be placed into a specific section (specified with asection(".section_name")
attribute). In general, when a function is considered for inlining, thesection
attribute is always ignored. However, with the link time optimizer enabled, the chances for inlining are much higher because the inliner works across multiple translation units. As a result, the output sections' sizes change compared to a non-LTO build. This may lead tosection ".section_name" will not fit in region "region_name"
type errors. - In all GCC versions, LTO removes C functions declared as weak in assembler (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966). For Mbed OS, the problem emerges when exporting Mbed OS projects to other build systems. You can fix this by changing the order of object files in the linker command: Objects providing the weak symbols and compiled from assembly must be listed before the objects providing the strong symbols.