Build -Os and -O2 versions of every target library #821
Conversation
|
@keith-packard that feature looks awesome, and as usual only two questions:
|
keith-packard
force-pushed
the
multilib-space
branch
from
8d05234
to
ccd100c
Compare
Yup, once we know how this will work upstream in gcc, we can figure out how to get it merged to ct-ng.
Yup, already submitted. https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665446.html |
keith-packard
force-pushed
the
multilib-space
branch
from
ccd100c
to
d5990cc
Compare
keith-packard
force-pushed
the
multilib-space
branch
from
d5990cc
to
dc13a5e
Compare
keith-packard
force-pushed
the
multilib-space
branch
2 times, most recently
from
fa1749a
to
e3595ae
Compare
|
This is actually working when I disabled newlib-nano to keep the build times in check. The only testing failure occurred when a newlib-nano test slipped through; that should be fixed with zephyrproject-rtos/zephyr#80161. Here's my best guess as to the space required for an x86_64 linux toolchain: This includes -Os and -O2 versions of picolibc, newlib and newlib-nano along with libstdc++ compiled for each one. We could probably hack things up so that newlib was only provided in -O2 version while newlib-nano only in -Os; that would save two thirds of the increase measured above. There isn't a great alternative here -- we can tell people to use the module when they need -O2, but that rules out using C++ with -O2. When can we consider reducing the number of C library variants provided in the SDK? |
I have cherry-picked that patch into the
I think trying to completely remove newlib from the SDK is going to be met with a lot of backlashes. Another option would be to remove newlib from the main SDK distribution and create a separate newlib "overlay," which can be downloaded and installed only if one needs it (similar to what LLVM Embedded Toolchain for Arm does). |
Thanks.
Yeah, was only thinking about newlib-nano.
That would save a huge amount of space, and should be fairly easy to implement. |
keith-packard
force-pushed
the
multilib-space
branch
from
e3595ae
to
abaa60e
Compare
|
@keith-packard crosstool-ng PR has been merged. Can you please open a PR for GCC and picolibc (or do upstream sync for it)? |
|
Will take care of this tomorrow. |
Need to use BUILD_DIR instead of WORKSPACE as the latter hasn't been set at this point. Signed-off-by: Keith Packard <[email protected]>
Make sure we catch build failures. Signed-off-by: Keith Packard <[email protected]>
Merge GCC version with multilib-space support which adds -Os versions of every multilib configuration. Signed-off-by: Keith Packard <[email protected]>
Make sure arc builds in -O2 mode successfully. Signed-off-by: Keith Packard <[email protected]>
This option passes --enable-multilib-space to gcc so that we get -Os versions of every multilib configuration. Signed-off-by: Keith Packard <[email protected]>
This provides -Os versions of every toolchain library. Signed-off-by: Keith Packard <[email protected]>
keith-packard
force-pushed
the
multilib-space
branch
from
abaa60e
to
6fd2e1d
Compare
|
I've got the GCC PR queued. zephyrproject-rtos/picolibc main is sync'd with picolibc main to pull in fixes for arc, xtensa and add uchar.h |
This uses a new gcc config option, --enable-multilib-space, which duplicates every multilib configuration, adding
a new version which optimizes for space. With this, every library in the toolchain will get built twice and will be selected
depending on the options applied during the link phase. Add -Os or -Oz and you will get space-optimized versions of every toolchain library.
crosstool-ng PR: zephyrproject-rtos/crosstool-ng#26
GCC PR: zephyrproject-rtos/gcc#39
Picolibc PR: TBD