Created attachment 227939 [details] patch It's well known that LTO provides both performance and size benefits for binaries. Add preliminary, opt-in support for global LTO enforcement to ports. Ports that provide LTO option on their own and the ones that don't work with LTO will need to set LTO_UNSAFE in the future. When the LTO is switched by default, it will need to be excluded on the platforms where LTO does not work, but the purpose of the patch is to give opt-in support.
Adding jbeich@ since he seems to be interested in LTO as well.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=fb5f03a87cf432751fae1f0ae7f29c9d4fc65917 commit fb5f03a87cf432751fae1f0ae7f29c9d4fc65917 Author: Piotr Kubaj <pkubaj@FreeBSD.org> AuthorDate: 2021-09-30 18:27:50 +0000 Commit: Piotr Kubaj <pkubaj@FreeBSD.org> CommitDate: 2021-09-30 18:27:50 +0000 Mk/bsd.lto.mk: add global LTO support for ports It's well known that LTO provides both performance and size benefits for binaries. Add preliminary, opt-in support for global LTO enforcement to ports. Ports that provide LTO option on their own and the ones that don't work with LTO will need to set LTO_UNSAFE in the future. PR: 258536 Mk/bsd.lto.mk (new) | 10 ++++++++++ Mk/bsd.port.mk | 4 ++++ 2 files changed, 14 insertions(+)
^Triage: Assign to committer that resolved
Awesome, but I am surprised to see this merged without an exp-run :D
(In reply to Evgeniy Khramtsov from comment #4) > if defined(USE_LTO) Ah, nevermind.
I think USE_LTO should be renamed as soon as possible to WITH_LTO (with warning for USE_LTO usage). USE_* variables are reserved for ports. User defined variables should not start with USE_ to avoid confusion.
this should have gone through a review process. the semantic is wrong, USE_* is reserver for internal stuff, for things that are user facing we usually do prefer WITH_ like WITH_DEBUG=yes which is then confusing for the users. Of course now when changing a CHANGE entry is necessary and a check for the presence of USE_LTO should raise a warning for a couple of month then an error for another couple of month then be removed entirely let's reopen the issue until this get fixed
aka it should have been modeled like bsd.ssp.mk
FYI: https://reviews.freebsd.org/D35873
I specifically sent a PR to get some feedback, but there was none.
The functionality is committed now, can be enabled with WITH_LTO=true, so marking this as "FIXED" now.
I'm unsure if closed PR is the best fit for asking, but let's at least try as LTO is really wanted feature for me: 1. When LTO enabled, is it still worth to use ccache? 2. Is there a way to enable LTO cache? (https://clang.llvm.org/docs/ThinLTO.html#incremental) 3. Can one enable no. 3 in poudriere? 4. Can one set linker threads same way as MAKE_JOBS_NUMBER? (Especially for poudriere since it's expected that each jail use only 1 CPU by default.) 5. And, finally, are there any plans to test/enable LTO for base system? If this isn't right place for such questions — I would be grateful for a suggestion where to ask.