Gentoo Archives: gentoo-user

From: Pandu Poluan <pandu@××××××.info>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
Date: Fri, 18 Nov 2011 16:52:49
Message-Id: CAA2qdGVFptuHDJN51=YGKRFFy+fZGyz5O+r+0s4RQXzrpihmaw@mail.gmail.com
In Reply to: Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed? by Pandu Poluan
1 On Nov 18, 2011 11:35 PM, "Pandu Poluan" <pandu@××××××.info> wrote:
2 >
3 >
4 > On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@×××××.com>
5 wrote:
6 > >
7 > > On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@××××××.info> wrote:
8 > > >
9
10 -----snip
11
12 > > >
13 > > > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream
14 says
15 > > > that graphite is stable, feature-complete, and production-ready since
16 4.5.3.
17 > > >
18 > > > To fully taste the effect of graphite, I even went the torturous
19 route of
20 > > > emerging gcc + libtool + binutils (in that order) twice, followed by a
21 > > > wholesale-rebuild of everything (emerge --emptytree), then tarballed
22 the
23 > > > result to my own "stage3.1" tarball to spare me the *huge* amount of
24 time
25 > > > required.
26 > > >
27 > > > I've deployed 3 systems with USE "graphite", and they *felt* snappier.
28 > > > emerge's *felt* slower, though. (no objective tests, I know).
29 > > >
30 > > > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one
31 more
32 > > > time, this time specifying CFLAGS "-march=native"... and I just
33 couldn't be
34 > > > happier with the resulting performance :-)
35 > > >
36 > > > Rgds,
37 > > >
38 > >
39 > > I might be wrong but don't you need to have the gcc's options for
40 > > graphite enabled to actually make use of the graphite framework? (You
41 > > might be using them but you haven't mentioned it.)
42 > >
43 >
44 > Yes. There are some CFLAGS incantations to add to fully utilize graphite,
45 else the optimizations would be marginal at best.
46 >
47 > That said, turning on the CFLAGS flags was a *very* involved process:
48 >
49 > 1. By default, "graphite" is disabled. So you can't directly turn on the
50 graphite-related CFLAGS option. You must first enable USE "graphite" and
51 re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will
52 pull in ppl and cloog-ppl.
53 >
54 > 2. I don't know if libtool and binutils need to be remerged, but I did it
55 just to be safe.
56 >
57 > 3. Now that gcc has been compiled with graphite support, you can turn on
58 the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags
59 recommended by upstream *might* make some programs run worse; be careful.
60 (I won't have access to my servers so I can't tell you which ones exactly).
61 >
62 > 4. At this point, I want gcc itself to be optimized. So, I remerged gcc
63 and libtool and binutils (in that order). Might be unnecessary, but I'm
64 anal like that :-)
65 >
66 > 5. Finally, universe-remerge (emerge --emptytree).
67 >
68 > As you can see, steps 4 & 5 are optional. And they indeed took a
69 *humongous* time to complete. But I am quite satisfied with the result.
70 Everything felt snappier compared to older boxen that haven't been
71 graphite-ed :-)
72 >
73 > Of course, YMMV.
74 >
75
76 Okay, found a forum thread discussing graphite and the proper CFLAGS:
77
78 http://forums.gentoo.org/viewtopic-t-850087.html
79
80 IIRC my CFLAGS looks very similar to the once @genstorm uses (scroll down
81 to approximately 80% down the page).
82
83 Now I never experienced *any* emerge failure, provided that I don't go
84 higher than MAKEOPTS="-j3". Set it higher and several packages failed
85 during compile. I don't know whose fault is that, but you've been warned
86 ;-)
87
88 Rgds,