Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use GCC wrapped ar & ranlib to enable LTO #1329

Merged
merged 1 commit into from Mar 20, 2024
Merged

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 <alastair@d-silva.org>
@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
57 checks passed
@valeros
Copy link
Member

valeros commented Mar 20, 2024

Thanks for the PR, merged!

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.

None yet

3 participants