Gentoo Archives: gentoo-dev

From: "Robin H. Johnson" <robbat2@g.o>
To: Gentoo Developers <gentoo-dev@g.o>
Subject: Re: [gentoo-dev] CFLAGS moved to ebuilds.
Date: Mon, 08 Dec 2003 22:37:06
Message-Id: 20031209043949.GA24593@curie-int.orbis-terrarum.net
In Reply to: [gentoo-dev] CFLAGS moved to ebuilds. by John Nilsson
1 On Tue, Dec 09, 2003 at 02:28:13AM +0100, John Nilsson wrote:
2 > Selecting the correct -m flags is an easy operation as you will get all
3 > information you'll need from /proc/cpuinfo. When it comes to selecting -f
4 > flags you'll have to know the bottlenecs of the code and what the optimization
5 > will do to the code. More importantly you will have to test and compare
6 > diffrent settings.
7 This is most definetly not a simple task. See the genflags package I
8 wrote for this purpose. It was a _lot_ of work, as even the format of
9 /proc/cpuinfo is different accross arches and kernel versions. More
10 annoyingly, the string for a given process as listed in that file has
11 tended to shift over kernel versions, making life harder.
12
13 > Needless to say this is a very daunting task to perform for an entire
14 > operating system. As the whole deal is so complex most of us will just trust
15 > some urban myth found in a quick google or on the mailing lists.
16 > This often leads to errors for new users, setting -03 as optimization or
17 > breaking a package with -ffast-math (as I have done a couple of times).
18 > Even when things work you can't guarantee a good optimization if you don't
19 > benchmark the system. The complexity of the issue ensures that what one
20 > finds as good optimization isn't necesary good for some one else.
21 Thats the express purpose that genflags was created for, to provide
22 users with a known good set of high-performance CFLAGS so they didn't
23 need to mess around with it too much.
24
25 > Then there is the issue about stability. Users are bound to break thing if
26 > they set flags on pure guess and the leave it at that. A huge amout of support
27 > queries on the mailing-lists and bugs.gentoo.org boils down to beeing unstable gcc
28 > settings. A solution mostyl used to remedy this problem is to use "strip-flags" in
29 > ebuilds to remove known unstable flags (or all flags in some cases).
30 strip-flags to remove problematic flags on a per ebuild basis is the
31 best solution. I do agree that unstable gcc settings are a big problem,
32 eg in a recent bug it turned out the submitter's system (an older
33 Pentium I) couldn't handle -O3 without flaking out. Reduce it to -O2 and
34 the box went fine (both for compiling and already compiled packages).
35
36 > What we would need here is a sytem that ensures that the default flags for
37 > compiling each application is the best you can do while keeping the sytem
38 > stable. The system should provide mature recomendations of flags for those of
39 > us willing to risk a little stability for absolute speed. The system should
40 > take advantage of the ordinary software improvment mechanism used by OSS
41 > projects: evolution. Small but measureable improvments that all users
42 > benefit from.
43 again, genflags was created for this. I've considered a sequel to
44 genflags based on the genetic optimization of compiler flags as
45 mentioned on Slashdot a while ago, but for lack of time, i'm not even
46 looking at doing it now.
47
48 Stable and high-performance is an per-system definition, as evidenced by
49 the bug I mentioned with -O3.
50
51 > Specification
52 > =============
53 > To implemnt a system like this the current use of CFLAGS and CXXFLAGS in
54 > /etc/make.conf will be limited to -m flags, (in the future this might be
55 > generated from /proc/cpuinfo for defaults). A new setting CSTYLE can be set to
56 > 'speed', 'size', 'debug' or 'oldstyle'.
57 > In each ebuild CFLAGS_SPEED, CFLAGS_SIZE and CFLAGS_DEBUG is populated with
58 > the machine indipendent flags found to result in the desired goal for that
59 > package.
60 > If the user set CSTYLE=oldstyle CFLAGS will override the perpackage flags
61 > otherwise it will be appended to the package flags.
62 Again, this is genflags integrated to the system.
63
64 > By having CFLAGS in ebuild we ensure that they are related to a specific set
65 > pf source code. Meaningful benchmarks can be carried out and improvments can
66 > be filed to bugs.gentoo.org.
67 Again, this is very much variable depending on your system, not just the
68 source code.
69
70 --
71 Robin Hugh Johnson
72 E-Mail : robbat2@××××××××××××××.net
73 Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
74 ICQ# : 30269588 or 41961639
75 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

Replies

Subject Author
Re: [gentoo-dev] CFLAGS moved to ebuilds. John Nilsson <john@×××××××.nu>