Re: -flto to become more of a routine - any change in opinion since 2011?
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.
Reply to: