Bluetooth: Controller: Support Link Time Optimizations (LTO)

[cvinayak]

Support for using Link Time Optimization (LTO) when
building application with open source Bluetooth Low
Energy Controller. This reduces code space usage.

Use Link Time Optimisation (LTO) when building Controller
with Isochronous channels support.

nRF53x SoCs has 256KB flash and using speed optimisation,
which is the default today, overflows flash when adding
new features related to ISO support.

Signed-off-by: Vinayak Kariappa Chettimada [email protected]

[henrikbrixandersen]

Is this really the way we want to go? Certain subsystems enabling LTO by default, other don't?

[cvinayak]

Is this really the way we want to go? Certain subsystems enabling LTO by default, other don't?

LTO has been introduced recently and not enabled for default across the builds probably for a reason? Atleast, for the Bluetooth Controller included builds, i am not observing any regression in my (may be limited) manual testing.

Suggestions welcome if we want all builds to be Link Time Optimized.

[henrikbrixandersen]

I think it's too early to automatically enable LTO, even for a subsystem. We are still seeing issues like #70305

[nordicjm]

Is this really the way we want to go? Certain subsystems enabling LTO by default, other don't?

Users can enable the setting if they want it manually, I don't really see the value in having it automatically set. Which, I would assume, would then cause problems if they use a debug build and try to step through the bluetooth code

[tejlmand]

I think it's too early to automatically enable LTO, even for a subsystem. We are still seeing issues like #70305

I agree, considering the complexity of Zephyr, the need for whole-archive, link post-processing, etc. then I think there are too many variables to enable this per-default.

Although this has been tested for a single sub-system, then what happens when that subsystem is combined with the myriad of other options / subsystems / SoCs which may not have been verified to work properly with LTO ?

Also, having this config option inside a sub-system can give the false impression that the setting only applies to part of the build, which is not the case.

Technically, if using partial linking of subsystems before a final linking it would be possible to apply lto on just part of the linking (gcc/ld) on a subsystem, but that's not what this setting does, and would be a completely different task 🙂 .

[tejlmand]

This is not a good location for this setting.

It may give the impression that LTO is only applied on this subsystem, which is actually not the case.
Enabling LTO here will enable LTO for the Zephyr build.

One may say, of course, that should be obvious, but in Zephyr we are actually having parts which could be using LTO while other parts would not be using it, for example for the TF-M secure build.

[cvinayak]

I have now added depends on ARM && BT_HCI_RAW, this will restrict LTO to samples/application that build only the controller subsystem (aka hci_uart, hci_ipc... and so on) with a HCI transport.

And on the hci_ipc for now needs reduced code space usage in-order to support ISO features and be able to have spare space for DFU.

[cvinayak]

Removed && BT_HCI_RAW as normal samples/application would like to use LTO.

[wopu-ot]

Looks like a typo snuck in here: "Optimazation" -> "Optimization"

[cvinayak]

Thanks, just realized that moving to choice means I need to also have the optimize for space which would be the alternative when optimize for speed need to be disabled (and no LTO) for the Controller.

[Thalley]

There are some interdependencies that looks messy to me.

Currently it's possible to set LTO and BT_CTLR_OPTIMIZE_FOR_SPEED

[cvinayak]

@henrikbrixandersen and @tejlmand please re-review.

@henrikbrixandersen and @tejlmand Any chance you can take a second look as to if the concerns are addressed?