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 🙂