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