On Tue, Mar 29, 2016 at 09:02:13AM -0700, Josh Triplett wrote: > Steffen Möller wrote: > > I admit to be a fan of link time optimisation and would like to see this > > challenge promoted towards more of a routine challenge to establish for > > our packages. I found this informative thread > > > > https://lists.debian.org/debian-devel/2011/06/msg00181.html > > > > that in particular sees the challenge for the buildds to cope with the > > additional demands on compute time and/or memory. With a couple of > > compiler versions down the road I still see no conceptional difference, > > except that possibly the build demons may have become more powerful > > compared with the average package size, especially so for the often > > embedded architectures. > > One thing has changed since then: GCC supports "slim" LTO objects, which > *don't* compile the code twice. A "fat" LTO object file contains both > intermediate representation and generated machine code, and you can > decide at link time to not use an LTO linker; a "slim" object contains > only intermediate representation, and can only be linked with LTO. > Using slim objects provides a significant reduction in build time.
In gcc-4.7 you had to specify -fno-fat-lto-objects, this is the default in current gcc. The memory usage of LTO has since improved drastically, but is still noticeable bigger than non-LTO. It doesn't require taking the whole program into memory at once anymore, though, thanks to partitioning. And as for buildds having improved, that too. Especially arm* are nothing like the laughing stock they once were. Mips* are far slower but at least the buildds are fine memory-wise. So I'd say you can safely enable LTO on all release architectures. And that "slow" mipsel? Some crazy Chinese are building supercomputers on Loongsons so scientific software is useful on those. Meow! -- A tit a day keeps the vet away.
