On Wed, 24 Aug 2016 11:21:33 -0400 (EDT) Nicolas Pitre <nicolas.pitre@xxxxxxxxxx> wrote: > On Wed, 24 Aug 2016, David Howells wrote: > > > Out of interest, does using LTO also fix the problem? > > With those patches in place, that would be the next thing to try. > Reducing our reliance on 'ld -r' will greatly help promoting LTO for the > kernel. > > Personally I'd like to have the choice between LTO and -gc-sections at > configure time. They both have advantages of their own. We discussed this in previous rounds of patches, but to just expand on Nicolas' answer with some overview: - Thin archives are needed for linking large kernels of some ISAs. I believe the linker becomes constrained in where it can use branch stubs when linking large inputs, but haven't looked into the internals exactly. There are a number of other ways proposed to solve it, but archives are well understood by toolchain and look like quite an elegant solution (with other benefits such as build output size and helping to enable LTO). - gc-sections patch is mainly to address some small regressions in binary size with the first patch, but I think the results make it stand on its own. It's very fast, mature, does not transform code, and gives surprisingly good size saving without much enablement work. The work that is required (e.g., to annotate entry points) is mostly shared with LTO if we add that in future, so it's not dead-end cruft. - LTO: Nicolas has posted far more significant size improvements with his more advanced work with reference annotatation and LTO. I'm surprised there has not been more interest, but I hope if we get this merged, it might give him motivation to look at it again. Discussion seemed to die down last time with people saying we should look at gc-sections first. I see this as enabler to LTO rather than a replacement. LTO is bigger change to build and less mature, but long term it is the right way to go IMO. When we iron out toolchains, perhaps have LTO option for just static elimination rather than transformations for high speed / low optimization builds, etc., then gc-sections would be completely supplanted could be removed. Using sections for dce is a nice linker hack, but real LTO information seems cleaner in the end (and of course allows more optimization). Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
