1 |
Mike Gilbert <floppym <at> gentoo.org> writes: |
2 |
|
3 |
|
4 |
> > CPU_FLAGS_X86="mmx sse sse2 sse3 ssse3 sse4 sse4_1 sse4_2 sse4a ssse3 \ |
5 |
> > mmx mmxext xop 3dnowprefetch 3dnow 3dnowext aes avx avx2 fma3 fma4 \ |
6 |
> > padlock popcnt " |
7 |
|
8 |
> Exactly how did you "surmise" your list? |
9 |
|
10 |
cat /usr/portage/profiles/desc/cpu_flags_x86.desc |
11 |
|
12 |
which is a subset of the CPU flags found in /proc/cpuinfo |
13 |
|
14 |
|
15 |
> > What would be cool, is if the devs took the entire list of cpu flags |
16 |
> > from proc/cpuinfo and piped it thru a simple validation script (equery |
17 |
> > hasuse) to generate the maximum flags to set by default for a given cpu. |
18 |
> That's exactly what cpuinfo2cpuflags-x86 does. |
19 |
|
20 |
So the list given by the current script does not include all of the |
21 |
flags listed in //usr/portage/profiles/desc/cpu_flags_x86.desc |
22 |
|
23 |
|
24 |
That's the explanation I was looking for. The only thing I can think |
25 |
of is the extra flags are not every used in current packages found |
26 |
in the portage tree. I wonder if gcc(++) might could make use |
27 |
of those flags. I'm not making a statement, but framing a question. |
28 |
|
29 |
But I would think that is the reason for the subset of /proc/cpuinfo |
30 |
that forms the flags listed in : |
31 |
/usr/portage/profiles/desc/cpu_flags_x86.desc |
32 |
|
33 |
hth, |
34 |
James |