On Thu, 2019-12-19 at 22:14 +0000, devel- request@xxxxxxxxxxxxxxxxxxxxxxx wrote: Igor, > Send devel mailing list submissions to > > It would be very nice to get more specific analysis data. Like running > some benchmarks of big applications, size comparisons (of binaries and > libraries) and compile time. Jan (from SuSE) probably has the best data on this. http://www.ucw.cz/~hubicka/slides/opensuse2018-e.pdf https://hubicka.blogspot.com/2019/05/gcc-9-link-time-and-inter-procedural.html I don't have his 2019 Cauldron slides which discuss the most recent improvements. I'll put those links into the change proposal. > > > This change also brings us back on-par with SuSE who enabled LTO by > > default for their free distribution earlier in 2019. > > You probably should have said openSUSE rather here. Yea, openSUSE is more appropriate here. I'll update that. > > > == Scope == > > * Proposal owners: > > The primary change is to redhat-rpm-config to add LTO to the default > > compile/link flags as well as a conditional which allows easy opt-out > > on a package by package basis. Additionally the post-build scripts > > need to strip the LTO bytecodes from any installed .o/.a files. > > What does that mean? Which post-build scripts are needed and where > that needs to be done? How does it affect build time? There's one post-build script which strips the LTO bytecode. Essentially it's just like stripping debug info or the static symbol table (like we already do), except we have to apply it to all the .o/.a files. The openSUSE guys already have these bits, odds are we'll just copy 'em. I wouldn't expect the stripping to be noticeable on the build time. LTO itself will certainly make things slower at build time. > > > Additionally, we know there are many packages with configure scripts > > that are compromised by LTO. I have tweaks to the %configure macro in > > redhat-rpm-config which fixes the vast majority of these problems with > > a few simple sed scripts on the generated output. Like the basic > > support for injecting the LTO flags, this will require coordination > > with the redhat-rpm-config maintainers. Packages which call configure > > directly and have compromised tests will need a one line change to > > their .spec files to fix their configure scripts. > > "simple sed scripts" are probably not so simple :) There's 5 sed scripts I'm using within %configure. Trust me, that's dramatically easier than trying to fix every package with broken configure scripts -- particularly when some of those configure files were built with versions of autoconf that are 12+ years old. Only two of the 5 sed scripts are, IMHO as a non-sed person, complex. This avoids the need to fix several hundred packages. There's certainly some straggler packages that have configure bits that are unique to those packages rather than shared across many packages. Those I expect we'll just fix on a per-package basis (it's measured in a dozen or two in the end I suspect). I have a tester which allows me to build all the Fedora binary packages. So I build once with gcc-10+LTO, capture the generated config.h files, then build again with the standard gcc-9 compiler. Then the resultant config.h files are compared. If there's any differences, the build is failed. > > > Some packages will need to opt-out of using LTO at this time. The > > most common case are packages that use symbol versioning or toplevel > > ASM statements. While there is a new mechanism to make LTO work with > > symbol versioning, I don't think any packages have been updated to use > > that mechanism. This will require a one line change to 50-75 packages > > (my script to find these is still running). > > Hmm, I think we have bunch of packages (more than 75 of them) which > use symbol versioning. Would be useful to give some links in the > change proposal to "how to update to use that mechanism". Yup. I've already got a (growing) list of 'em. I've got ~50 on my list and ~125 failures still to evaluate. Ideally the opt-out mechanism for a package's .spec file would look like: %undefine _lto Simple enough? :-) Jeff _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
