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 |