Conversation
|
Preliminary run from the examples directory: Use the following to build stuff: results from Edit: Updated |
|
Added more fixes |
|
@gebart Arent "fat LTO objects" objects that contain not only, e.g., a compiled function, but also the intermediary representation, so the linker can "compile" the IR of multiple objects into the final binary, allowing even more optimization? (needs rebase) |
|
The non-fat LTO objects contain only the IR code in order to allow the linker to optimize further. The fat LTO objects contain the same information, but also the traditional binary object code, which can AFAIK not be used by the LTO process, but allows an older linker to still link the objects, by simply discarding the IR version of the code. |
6455b6c to
645c1b6
Compare
|
rebased, untested. |
645c1b6 to
15dccd1
Compare
|
Updated list with both GNU and LLVM toolchains (TOOLCHAIN is only relevant for cortex-M platforms, other results are only gcc regardless of what TOOLCHAIN says): Generated by running: for f in */; do for t in llvm gnu; do for l in 0 1; do make -C $f clean buildtest BUILD_IN_DOCKER=1 BINDIRBASE="TOOLCHAIN=${t}-LTO=${l}" TOOLCHAIN="${t}" LTO="${l}"; done; done; done
for f in */; do for t in llvm gnu; do make -C $f info-buildsizes-diff NEWBIN=TOOLCHAIN=$t-LTO=1 OLDBIN=TOOLCHAIN=$t-LTO=0; done; done | tee info-buildsizes-diff-lto.txt | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" | expand > info-buildsizes-diff-lto-nocolor.txt
for f in */; do for l in 0 1; do make -C $f info-buildsizes-diff NEWBIN=TOOLCHAIN=llvm-LTO=$l OLDBIN=TOOLCHAIN=gnu-LTO=$l; done; done | tee info-buildsizes-diff-toolchain.txt | sed -r "s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g" | expand > info-buildsizes-diff-toolchain-nocolor.txtEdit: I noticed that I must have done something wrong when I built with LLVM, I don't expect all sizes to be exactly the same with Clang and GCC. |
|
@gebart What's the state on this? |
|
I did not touch it since my last post. It needs to be tested on real
hardware.
|
cpu/arm7_common/syscalls.c
Outdated
There was a problem hiding this comment.
Why is used needed? For library functions?
|
IMHO this should get a lot more attention. @gebart could you rebase, please? I'll try to help... |
|
sorry, I forgot to rebase, won't make it for release |
gcc-ar is a wrapper supplied by gcc for properly handling thin LTO objects.
…ith info-boards-supported etc.
No ROM cost, only fixes a linker error with non-nano newlib and LTO enabled.
|
I just got LTO for cortex-m working, by making it possible to exclude some .c from being compiled with -flto. I'm about to open a PR, should I cherry-pick your other LTO fixes? |
|
I think the easiest is to rebase my branch on top of this. |
|
Postponed due to feature freeze |
|
Where did we leave here? |
|
yes, let's close. |
(based on top of #3163 and #3358)- mergedThis PR intends to make all modern platforms build properly with LTO.
Including:
__attribute__((used))when necessaryPass LTO variable to Docker container- merged in Pass LTO flags to sub-environments buildtest and Docker #4751Pass LTO variable to- merged in Pass LTO flags to sub-environments buildtest and Docker #4751make buildtestgcc-arwrapper for building archives when building with LTOTODO:
-ffat-lto-objectsis needed. (Does LTO even make sense if the tools require fat LTO objects?)__attribute__((used))).info-buildsizes-difffor comparison