Gentoo Archives: gentoo-dev

From: Andrew Savchenko <bircoph@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: LTO use in the tree
Date: Mon, 28 Apr 2014 21:08:42
Message-Id: 20140429010814.9b92f98ee76f019e25950340@gmail.com
In Reply to: Re: [gentoo-dev] Re: LTO use in the tree by "C. Bergström"
1 Hello,
2
3 On Sun, 27 Apr 2014 07:34:05 +0700 C. Bergström wrote:
4 [...]
5 > Not to be a smart-ass, but will someone start a thread on global
6 > PGO (profile guided optimizations) next? imho it would be
7 > interesting and great to have some general training data already
8 > contributed next to the ebuilds. For the science stuff I wouldn't
9 > recommend it, but who knows..
10
11 Global PGO is meaningless, because PGO requires not just compiler
12 flags, but package-specific tests covering all widely used profiles
13 for package in question. So this requires intensive upstream work
14 and in no way can be done in Gentoo for any significant number of
15 packages.
16
17 At this moment only two packages in tree support PGO: dev-libs/gmp
18 and www-client/firefox. For gmp it works great. For firefox it is a
19 menace:
20 1) with current in-tree firefox versions PGO can't be used on x86
21 at all, since linker doesn't fit in 3GB memory limit, even with
22 memory-constraint options, both GNU ld and gold.
23 2) on amd64 4GB is surely not enough for linking of profile-enabled
24 version, so I can't use it here too.
25 3) Old firefox versions (somewhere around 18) were successfully
26 compiled on the same ~x86 and ~amd64 boxes. So something in
27 firefox tree changed that much.
28
29 There is also sci-libs/atlas in the science overlay which uses
30 similar technique during build. But strictly speaking this is not
31 PGO, as changes are made on algorithm level rather than on
32 compiler's one: it test each block with different parameters and
33 choses the fastest ones for current box.
34
35 Best regards,
36 Andrew Savchenko