So, I’ve been having tonight the craziest idea possible 😛 Deprecating mmx, 3dnow, sse, and similar useflags. Let’s try to get a reason for that tho 🙂
So, mmx, 3dnow and sse useflags are used to enable special CPU-specific features that people might not have on their CPU. It’s not a good idea to enable them everywhere, but it’s often a bad idea do not enable them at all if you support them.
Unfortunately, it’s not always clear when to enable them and when not, and it’s difficult to handle them all considering that on amd64 they are usually all enabled… but 3dnow is not present on nocona arch (Intel EM64T arch).
I was tonight thinking of something like this:
has_mmx() {
echo | $(tc-getCC) ${CFLAGS} -E -dM - | grep -q "#define __MMX__ 1"
}
with that function, you can check if the user asked to support a processor with MMX enabled, by using the user-supplied CFLAGS.
When you use -march you tell GCC to enable different extensions to the instruction set, so if you ask for an athlon-tbird arch, you’ll get MMX and 3DNow!, while if you ask for nocona you won’t get 3DNow! at all.
To disable one feature even when we know the arch we’re building for does have that extension, or to enable one even if we have a lesser arch (does not make much sense, but you never know), you can use -mno-mmx or -mmmx flags, that in 99% of the cases are misused by ricers.
This works for all the cpu-extensions flags we have, even altivec, and is safe to use with every GCC version. So why not? This will also reduce the arch tests, you can even use this function
is_x86() {
echo | $(tc-getCC) ${CFLAGS} -E -dM - | grep -q "#define __i386__ 1"
}
to check if you’re building for x86 systems, no need either to think of ${ARCH} and similar…
I think I’ll be proposing this officially tomorrow, it might help 🙂
interesting idea, problems:- granularity : no per ebuild cflags yet- syntax : less easy to guess since is hidden in the -mcpu/-mtune, but probably that’s good.- compatibility : some people use non gcc compilers, will it work?
that’s a bug in this idea.let’s say i wanna just build for fun or build experimenting or (and this is the best) build on my machine, for another machine.so you’ll deny this.
Hetfield: if you’re cross compiling, the cross-compiler will show up in $(tc-getCC), and the generated #defines will be correct. If you want to temporarily turn MMX off, you can just add -mno-mmx to your CFLAGS as needed.I think this is a great idea.
Hetfield you’re missing one point. If you have, say, an athlon-xp, and you want to build a package for an i586 (that has mmx but no 3DNow! and no SSE), you _cannot_ leave -march=athlon-xp, or you’ll generate broken code anyway; you’ll need to use -march=i586 -mmmx, which will generate the correct code allowing for the correct selection.Also, as Michael said already, -mno-mmx will allow you to disable MMX support altogether.
There is also another problem. What if the GCC auto-mmx or auto-sse gives broken code for a specific program, but you still want to use the hand crafted asm code… I know that early gcc 3 had many problems with SSE2 optimisations, but maybe this really is a weird case.
Then the ebuild should use
append-flags -mno-mmx(even without this idea).If the ebuild tests for
__MMX__before adding-mno-mmx, there’s no problem.I like it a lot. About non-GCC compilers though, I’d like to know too if there’s any way of not breaking things for them any more than they are already.What about a useflag that causes the ebuild to grep for the right optimizations? It could even grep /proc/cpuinfo if you like! If you want to cross-compile you just unset the USEflag and set your own optimizations.