Skip to content

Conversation

@deece
Copy link
Contributor

@deece deece commented Mar 14, 2024

As per platformio/platform-ststm32#386

Link Time Optimisation shifts compilation to the final link, allowing for more aggressive optimisations.

AR & RANLIB need to use their gcc equivalents to enable this, and will otherwise behave identically if LTO data is not in the objects.

(This should probably be done for all platforms)

LTO shifts compilation to the final link, allowing for more aggressive optimisations.

AR & RANLIB need to use their gcc equivalents to enable this, and will otherwise behave identically if LTO data is not in the objects.

Signed-off-by: Alastair D'Silva <[email protected]>
@deece
Copy link
Contributor Author

deece commented Mar 15, 2024

Note: This appears to a rehash of #702

@Jason2866
Copy link
Contributor

Using LTO since over a year with project Tasmota and it is working.
Knowing from maintainer of project EspEasy he is using too and it works well here too.

@valeros
Copy link
Member

valeros commented Mar 15, 2024

The espressif32 dev-platform is more popular than ststm32, so all steps regarding build system should be carefully considered. LTO in embedded builds is a controversial topic, so I'm a bit reluctant to enable it by default, mainly because of the aggressive optimizations as you mentioned. We try to differ as little as possible from the original tools used in frameworks, so if you still interested in enabling LTO for ESP32 targets, please file a feature request in the Espressif repositories in the first place.

@Jason2866
Copy link
Contributor

@valeros espressif Arduino is already using elf-gcc-ar espressif/arduino-esp32#8013

@valeros
Copy link
Member

valeros commented Mar 16, 2024

@Jason2866 thanks for the info. I didn't notice this change in 2.0.14, so I believe it's currently only available in the core dev branch for v3.x?

@Jason2866
Copy link
Contributor

Jason2866 commented Mar 16, 2024

@valeros Yes, it is added in dev branch v3.x and will be there in release v3.0.0
I added in my fork for core 2.0.14 and it is working there too.

@deece
Copy link
Contributor Author

deece commented Mar 16, 2024

@valeros this change in itself doesn't enable LTO, it just removes things that get in the way of enabling it.

It should be completely transparent to non-LTO builds.

@Jason2866
Copy link
Contributor

Jason2866 commented Mar 16, 2024

Exactly, without explicit enabling LTO there will be no change in compiled code by merging the PR.
Yes, imho LTO should always disabled by default in an standard setup. This is the case here. The build scripts have explicitly set -fno-lto. So this changes is full backwards compatible.
https://github.com/espressif/arduino-esp32/blob/75b7f4b646599426e92ebec913a4dce14ef528cd/tools/platformio-build-esp32.py#L84

@valeros valeros merged commit 271f417 into platformio:develop Mar 20, 2024
@valeros
Copy link
Member

valeros commented Mar 20, 2024

Thanks for the PR, merged!

jonathandreyer pushed a commit to jonathandreyer/platform-espressif32 that referenced this pull request Nov 14, 2024
LTO shifts compilation to the final link, allowing for more aggressive optimisations.

AR & RANLIB need to use their gcc equivalents to enable this, and will otherwise behave identically if LTO data is not in the objects.

Signed-off-by: Alastair D'Silva <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants