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

Enable LTO build #77

Open
wants to merge 3 commits into
base: 0.8.2-dev
Choose a base branch
from
Open

Enable LTO build #77

wants to merge 3 commits into from

Conversation

ashquarky
Copy link

This PR includes changes to mark the important .wups sections with the "used" attribute. This ensures that even aggressive optimisations (e.g. LTO) will not remove the hooks and WUPS metadata.

Since the used attribute needs to be on the variable itself (not an extern), move all attributes to the used attribute. extern in C++ also implies C linkage, so specify C linkage.

With that groundwork in place, enable an LTO build. This isn't super important - the used attributes are needed for plugins to use LTO - but it's basically free to enable it for the library too, so why not?

This is already provided by BUILD_CFLAGS later on
If we put something in a given section, we should be able to expect it to actually turn up in that section!

Doing this will prevent LTO from slurping all the hooks away as "unused".
This uses "fat" binaries, so normal builds won't break, but also includes the LTO data for builds that wish to use it
@Maschell
Copy link
Collaborator

Maschell commented Nov 22, 2024

How "safe" is it to use lto, i've been told
that this can be quite unstable from time to time. Maybe remove this from WUPS to be sure, i doubt it'll have any big impact on this lib anyway?

@ashquarky
Copy link
Author

LTO is used by the PPC64 builds of Firefox - so it can at least hold its own for the most complex piece of C++ imaginable for a similar CPU arch. It used to be pretty buggy but word is that it's much improved.

Note I enabled -ffat-lto-objects - this means that if the plugin doesn't use LTO, they will be completely unaffected by this change. That flag basically runs two compiles - one normal, one LTO, and puts the results of both in the .o files. So every plugin in the wild will just ignore the LTO parts of the file and get the same -O2 code they've always had. You can confirm this with readelf, they add a bunch of new sections like .gcc_lto_main.c_...

So even if LTO on ppc32 does generate buggy code, plugin developers have to opt-in to it by passing -flto to the final, plugin link step; nobody does this so every plugin in the wild will not be affected. That's why I said it was "basically free"; for plugin devs who want to play with it.

@ashquarky
Copy link
Author

(the use, for what it's worth, is that I'm trying to get the binary size down for Inkay as much as possible, given that it's basically a shell plugin at this point with nothing but a config menu in it. I know there are constraints on binary size that the Aroma website imposes, so I'd like to make room for actual features 💙)

@Maschell Maschell changed the base branch from main to 0.8.2-dev November 28, 2024 18:42
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.

2 participants