Main issue isn't that it break stuff but that it tend to be pretty slow to compile with it.
reply.. that's why you compile without LTO during development and do a final 'compile with LTO > profile > fix / optimize > compile with LTO' pass.
replyCompilation happens once and then runs on hundreds of thousands up to billions of devices. Respect your users.
This assumes that LTO is strictly better than no-LTO, ie only gets faster, has the same optimization hotspots, and doesn't break anything.
replyI would recommend only doing things that fit within the 'build > text > fix' loop.
Which doesn't matter at all in a release build. And in a dev build it's rarely necessary.
replyAt FAANG scale the cost is prohibitive. Hence the investment in ThinLTO.
replyAt FAANG scale, you absolutely want to have a pass before deployment that does this or you're leaving money on the table.
replyIt's not as obvious a win as you may think. Keep in mind that for every binary that gets deployed and executed, it will be compiled many more times before and after for testing. For some binaries, this number could easily reach the hundreds of thousands of times. Why? In a monorepo, a lot of changes come in every day, and testing those changes involves traversing a reachability graph of potentially affected code and running their tests.
replyHow many Linux distributions use LTO? It is a rarity among Gentoo users as far as I know and that is the one place where you would expect more LTO usage.
reply