| |||||||||||||
Link-time optimization for the kernelLink-time optimization for the kernelPosted Aug 21, 2012 15:25 UTC (Tue) by ewan (subscriber, #5533)Parent article: Link-time optimization for the kernel "The fact that most people will not want to do LTO builds actually poses a bit of a problem." As long as there are Gentoo users there will be someone to test massively resource intensive compiler optimisations of uncertain benefit.
(Log in to post comments)
Link-time optimization for the kernel Posted Aug 21, 2012 16:29 UTC (Tue) by rvfh (subscriber, #31018) [Link]
You're trolling...
Link-time optimization for the kernel Posted Aug 21, 2012 16:59 UTC (Tue) by Homer512 (subscriber, #85295) [Link]
But not far from the truth:
http://realnc.blogspot.de/2012/06/building-gentoo-linux-w...
(Gentoo user myself, so this is not meant mockingly)
Link-time optimization for the kernel Posted Aug 23, 2012 0:53 UTC (Thu) by prometheanfire (subscriber, #65683) [Link]
Someone has to find the bugs.
Link-time optimization for the kernel Posted Aug 21, 2012 17:08 UTC (Tue) by mikemol (subscriber, #83507) [Link]
Yet he's right. And I say this as an enthusiastic Gentoo user who's done some automation to find optimum configurations. :)
In reality, though, building a kernel with LTO isn't going to take as long as, say, building LibreOffice, Firefox or Chromium. Those take sufficiently long that more than a few Gentoo users prefer to use binary ebuilds rather than build them themselves.
What's really needed here, though, are automated regression tests to improve the confidence that the output of an LTO build isn't the most likely source of problems. That's the kind of thing that would need massive corporate sponsorship to get off the ground, though; there's a *ton* of code in the kernel, and while it's reasonably well-organized, that's still a lot of tests to write.
It's also necessary to understand that you can't be 100% confident you've caught all possible compiler-introduced bugs. The best you might be able to do is identify the portions of the kernel which the LTO pass twiddled the most, and write additional tests to exercise that code from multiple angles.
I wonder if such an "LTO hotspot" analysis could be used to do certain high-level reasoning about the code. Being able to answer questions like "given that LTO-active regions have some relation to a property of the APIs in that area, is that property something we want to see more or less of in our APIs?" would be interesting; it could help inform tradeoffs in future designs of APIs.
|
|||||||||||||