At Least 27% Of Gentoo's Portage Can Be Easily LTO Optimized For Better Performance

[Grinch]

what gets inlined where by the compiler during LTO. If A is using library B and B is using C, it means that the internal code from B and C might end up in A. If the user updates library C, the package manager must be able to detect that it needs to rebuild A and B depending on where the compiler decided to inline C into.

I don't follow, unless you explicitly tell the compiler to statically link external libraries, they won't be part of the final binary just because you use LTO.

[geearf]

You don't seem to realize how often people use the size of the largest mass storage drives as a metric for evaluating how large the software should be.

LTO is not only about size though.

[skeevy420]

Dammit. I didn't need any more reasons to want to try GentooLTO out and now I have at least 5,146 more

It's been on my "wants to do" list since February.

[dispat0r]

I am a Gentoo user and I don't see how LTO can be made stable on a rolling release Linux distribution without detailed records about what gets inlined where by the compiler during LTO. If A is using library B and B is using C, it means that the internal code from B and C might end up in A. If the user updates library C, the package manager must be able to detect that it needs to rebuild A and B depending on where the compiler decided to inline C into. The most pessimistic approach (without any tracking of what the compiler actually inlines where) is for rebuild_C to always trigger rebuild_B and rebuild_A. There can be longer dependency chains like A -> B -> C -> D -> E. This also implies that upgrade_GCC should automatically trigger rebuild_allpackages.

I don't see any indication that GentooLTO is a serious mathematically correct attempt to automate handling of LTO dependencies by tracking the inlining of code&data in a rolling release Linux distribution. If somebody was able to find such an indication, please post it here.

I'm one of the 30 users and never had to rebuild all packages because of a gcc update. The only problem you can encounter is if you try to build a LTO package with an older gcc version and the libraries a build with a newer gcc version. I encountered that with some kde plasma/qt packages.

[FireBurn]

I am a Gentoo user and I don't see how LTO can be made stable on a rolling release Linux distribution without detailed records about what gets inlined where by the compiler during LTO. If A is using library B and B is using C, it means that the internal code from B and C might end up in A. If the user updates library C, the package manager must be able to detect that it needs to rebuild A and B depending on where the compiler decided to inline C into. The most pessimistic approach (without any tracking of what the compiler actually inlines where) is for rebuild_C to always trigger rebuild_B and rebuild_A. There can be longer dependency chains like A -> B -> C -> D -> E. This also implies that upgrade_GCC should automatically trigger rebuild_allpackages.

I don't see any indication that GentooLTO is a serious mathematically correct attempt to automate handling of LTO dependencies by tracking the inlining of code&data in a rolling release Linux distribution. If somebody was able to find such an indication, please post it here.

You're a Gentoo user, you should be recompiling everything anyway when you get a new version of GCC #gccChristmas

[FireBurn]

There was a recent change to portage that should stop stripping important stuff required for LTO from static libraries that Qt tends to use

[darkbasic]

You're a Gentoo user, you should be recompiling everything anyway when you get a new version of GCC #gccChristmas

Exactly, what's the point of using Gentoo if you don't recompile everything any time a new major version of GCC gets released?

[RealNC]

They're using Graphite, which is unmaintained, abandoned, and nobody cares about it. This doesn't exactly inspire confidence for the people behind this overlay...

[RealNC]

If A is using library B and B is using C, it means that the internal code from B and C might end up in A.

Eh? How would that happen?

[Weasel]

Eh? How would that happen?

If the compiler decides to inline it into A. WIth LTO, it can see the function definition, so it might inline it.