Gentoo Archives: gentoo-dev

From: "Kevin F. Quinn" <kevquinn@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Date: Fri, 07 Jul 2006 15:43:07
Message-Id: 20060707174614.1180d82d@c1358217.kevquinn.com
In Reply to: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles by Danny van Dyk
1 On Fri, 7 Jul 2006 16:20:08 +0200
2 Danny van Dyk <kugelfang@g.o> wrote:
3
4 > OK, this rfc/proposal is competing with Flameeye's proposal:
5 >
6 > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree.
7
8 I don't like the name - I'd prefer something like CPU_SUBMODEL or
9 CPU_FEATURES or perhaps ARCH_FEATURES. I agree with Diego, I don't see
10 this gets us anything we don't already have - it becomes just a USE
11 flag list tidy-up (c.f. INPUT_DEVICES et. al.).
12
13 > This should be set to sane defaults in the profiles. I.e. for x86,
14 > it should not set CPUFLAGS at all, and on AMD64 it should be
15 > CPUFLAGS="mmx sse sse2"
16 >
17 > I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty,
18 > and ppc/ppc64 should set
19 > CPUFLAGS="altivec".
20
21 It would be nice to be able to specify the sub-model using the gcc arch
22 name, as well as by just listing the various features supported. It
23 would be even tidier if by default it would expand to the
24 common-denominator features supported by any -march setting in CFLAGS.
25
26 I'm thinking that from a user's perspective, they could:
27
28 a) set -march=<something> in CFLAGS, and the CPU_SUBMODEL would be
29 determined automatically
30
31 b) set CPU_SUBMODEL to an arch, for brevity; e.g.
32 CPU_SUBMODEL="athlon-xp"
33
34 c) set CPU_SUBMODEL to a set of features; e.g. CPU_MODEL="mmx sse sse2"
35
36 d) set CPU_SUBMODEL to a combination of the two; e.g.
37 CPU_MODEL="athlon-xp sse3"
38
39 e) not bother setting CPU_SUBMODEL at all, letting portage work out a
40 sensible set
41
42 To do this means more than just a USE_EXPAND, however. Obviously
43 portage is not a good place to store information about what submodels
44 support which features; this could be done via a file in the profiles;
45 e.g. profile.submodels:
46
47 athlon mmx 3dnow 3dnow_a
48 athlon-xp mmx sse 3dnow 3dnow_a
49 nocona mmx sse sse2 sse3
50 pentium
51 pentium-mmx mmx
52 pentium-m mmx sse sse2
53
54 and so on.
55
56 > The main reasons for a USE-like implementation om contrast to Diego's
57 > proposal are:
58 >
59 > a) There is no call to gcc involved, but only a call to use(). This
60 > allows usage in metadata phase.
61 > b) There is no implicit (non-transparent) choice made for the users.
62 > c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo)
63 > with the purpose of optional codepaths.
64 >
65 > I know, there aren't use-based deps in portage yet, but I really feel
66 > uncomfortable to be unable to use cpuflags in metadata phase. This is
67 > what worries me most.
68
69 The only thing my CPU_SUBMODEL conflicts with here is (b), in that the
70 submodel features appropriate to the CFLAGS -march setting are
71 automatically set.
72
73 A downside is that there is still redundancy between CFLAGS and
74 CPU_SUBMODEL; e.g. an sse3-enabled athlon user would set
75
76 CFLAGS="-march=k8 -msse3"
77 CPU_SUBMODEL="k8 sse3"
78
79 (for a k8 processor that also has sse3) which seems a little daft. It
80 does highlight that we're controlling two things, however; one being
81 what type of code is generated by gcc (CFLAGS) and the other being the
82 configure enable/disable bits (CPU_SUBMODEL).
83
84 Diego's proposal essentially generates CPU_SUBMODEL automatically from
85 CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not
86 set. That way we have the best of both worlds; people who are happy to
87 let the system determine the configure options from the compiler
88 architecture can do so, those who want to control things in more detail
89 can do that as well.
90
91 --
92 Kevin F. Quinn

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles Martin Schlemmer <azarah@××××××××××××.org>
[gentoo-dev] Re: [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles Duncan <1i5t5.duncan@×××.net>