Public bug reported: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package.
Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/2058017 Title: openssl is not LTO-safe Status in openssl package in Ubuntu: New Bug description: tl;dr: since it's too much work to make openssl LTO-safe, upstream doesn't see it as a goal and doesn't test it, and there are probably no performance gains to LTO for this package. Openssl is an old project and the codebase wasn't written with aliasing rules in mind. There are several reports of issues related to LTO. The openssl technical commitee says "currently we're not going to fix all the strict aliasing and other LTO problems" and "Fixes raised in pull requests will be considered."; in other words: if you find a violation, we'll merge your fixes but we're not going to dedicate time to fixing them ourselves. We don't have specific reports on launchpad at the moment but but we cannot rule out that we're already experiencing miscompilations and compilers are only pushing this further and further. This is impossible to know in advance and even security updates could trigger issues. Gentoo prevents usage of LTO for openssl and has some links related to this at https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/openssl/openssl-3.2.1-r1.ebuild#n131 : - https://github.com/llvm/llvm-project/issues/55255 - https://github.com/openssl/openssl/issues/12247 - https://github.com/openssl/openssl/issues/18225 - https://github.com/openssl/openssl/issues/18663 - https://github.com/openssl/openssl/issues/18663#issuecomment-1181478057 Gentoo also prevents usage of -fstrict-aliasing and always set -fno- strict-aliasing. I don't plan to do the same at least at the moment and for Noble since I don't have time to investigate more changes. Performance shouldn't be impacted much if at all: - crypto algorithms are implemented in ASM (funnily, using C implementations can trigger issues because these can get miscompiled) - the rest of the openssl codebase probably doesn't benefit from LTO because source files match codepaths quite well - at the moment, openssl performance for servers is bad due to algorithmic/architectural issues, not micro-optimizations and these wouldn't be noticed - if LTO-compliance was doable and thought to be useful by upstream, they would have certainly pushed that forward, especially in the wake of openssl 3.0's performance issues. Code size increases by a few percents except for libcrypto which gets 17% larger. The corresponding .deb file increases by 2.6% only. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2058017/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
