enable GCC link-time optimization

[zephyrbot]

Reported by Andrew Boie:

As a developer, I would like to enable link-time optimization to further optimize the kernel I am building.

It appears this may have been supported at one point as some arches have this in their Makefile:

cflags-$(CONFIG_LTO) = $(call cc-option,-flto,)

But CONFIG_LTO is not defined in any Kconfig anywhere, and these definitions should be moved out of arch makefiles.

(Imported from Jira ZEP-585)

[zephyrbot]

by Sharron LIU:

Will execute all existing test cases with LTO enabled, to ensure no regression introduce. Thanks.

[zephyrbot]

by Andrew Boie:

This task is a heavy lift and is highly at risk for 1.7.0, suggest to move to 1.8.0.

[zephyrbot]

by Mark Linkmeyer:

Fixing incorrect priority

[zephyrbot]

by Andrew Boie:

Robert Beatty Mark Linkmeyer
Not feasible for 1.7.
Recommend we punt to "future" given current priorties (ISH support, MCUBoot, etc)

[zephyrbot]

by Robert Beatty:

Andrew Boie , moving to {{v1.9}} and resetting to {{NEW}}

[SebastianBoe]

+1

It will be really interesting to see the results of supporting LTO.

[markuckermann]

Can I ask what the state of this is? LTO would be really nice to have I think!

[keith-zephyr]

I haven't looked at the blockers for enabling LTO on the Zephyr tree in a while. In a downstream repo, we enable LTO on our application specific files and disable LTO for the Zephyr files.

LTO on just our application specific files saves roughly 5% flash space.

[SebastianBoe]

When I experimented with LTO+Zephyr I found some integration issues with the scripts that zephyr uses to parse it's build files and do multiple link passes that I was unable to solve.

The build time was also significantly increased since a lot of work is moved from the parallell compilation to the serial link.

So it's not trivial, or for everybody, to enable LTO, but it definitely does make smaller/faster firmwares.

[markuckermann]

LTO on just our application specific files saves roughly 5% flash space.

That's a good saving. In our case, zephyr makes up the majority of the code so the potential is quite a bit larger

The build time was also significantly increased since a lot of work is moved from the parallell compilation to the serial link.

Sure, but it's a trade-off I'd like to have at least the option of making. Seems pretty important for embedded systems to have smaller / faster firmwares.

I guess, what I'm asking is: Why is the priority set to "low" for an issue that would enable instant space and efficiency gains on a project that prides itself on running on small resource hardware?

[clamattia]

I just want to mention, that our project would also benefit from LTO.

[clamattia]

@tejlmand is this fixed by version 3.6s https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_LTO ?