| 1 |
On Thu, 6 Jul 2006 12:52:29 +0200 "Diego 'Flameeyes' Pettenò" |
| 2 |
<flameeyes@g.o> wrote: |
| 3 |
| Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags |
| 4 |
| present in the tree, almost never used to get new dependencies, but |
| 5 |
| usually used to supply econf switches. |
| 6 |
| |
| 7 |
| This works as long as the user enable the flags, but for AMD64 the |
| 8 |
| story was, until now, that we simply enabled them when they worked, |
| 9 |
| because we had some minimum support available. Unfortunately this |
| 10 |
| became a problem with the introduction of nocona, because that is an |
| 11 |
| amd64-like system but with no 3dnow. And there is the problem that |
| 12 |
| sse3 is supported only in later versions of Athlon64 and so on. |
| 13 |
|
| 14 |
The other option here... Is to rename the x86 flags to x86_mmx, |
| 15 |
x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not |
| 16 |
really the same as the x86 flags. |
| 17 |
|
| 18 |
There's probably some USE_EXPAND trickery that can be used here... |
| 19 |
CPU_FEATURE_X86="mmx sse" -> cpu_feature_x86_mmx etc might be cleaner? |
| 20 |
|
| 21 |
| To try to clean up this mess, and to make it simpler to work in |
| 22 |
| cross-compilation, I thought of using the definitions created by the |
| 23 |
| C Preprocessor (CPP) by default for the given CFLAGS. Basically when |
| 24 |
| using -march=athlon64, the preprocessor will enable a few definitions |
| 25 |
| that tells the availability of MMX, 3dNOW, SSE and so on... if we |
| 26 |
| wrap that around, we can use it to know if it's the case of enabling |
| 27 |
| something or not. This is customisable by the user by setting the |
| 28 |
| CFLAGS themselves. If one does not want MMX instructions to be |
| 29 |
| generated, but still want the rest of Athlon64 optimisations, it's |
| 30 |
| simply the matter of using "-march=athlon64 -mno-mmx". |
| 31 |
|
| 32 |
Sounds rather flaky and unreliable... |
| 33 |
|
| 34 |
| SPARC team: I'd like to know if VIS does a similar thing, would make |
| 35 |
| simpler for instance its handling in xine-lib ebuild. |
| 36 |
|
| 37 |
VIS is present on all v9 CPUs. GCC's VIS support, however, sucks. |
| 38 |
|
| 39 |
-- |
| 40 |
Ciaran McCreesh |
| 41 |
Mail : ciaran dot mccreesh at blueyonder.co.uk |
| 42 |
|
| 43 |
|
| 44 |
-- |
| 45 |
gentoo-dev@g.o mailing list |
Archives