Move the MMX subtarget feature out of the SSE set of features and into

Description

Move the MMX subtarget feature out of the SSE set of features and into
its own variable.

This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.

Rationale:

// sse3
m128d test_mm_addsub_pd(m128d A, __m128d B) {

return _mm_addsub_pd(A, B);

}

// mmx
void shift(m64 a, m64 b, int c) {

_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);

}

clang -msse3 -mno-mmx file.c -c

For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.

This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.

Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.

This is paired with a patch to clang to take advantage of this behavior.

Details

Committed
echristoOct 8 2015, 1:10 PM
Parents
rL249730: Revert "[lsan] [aarch64] Add support for AArch64"
Branches
Unknown
Tags
Unknown

Now that this is in place would it make sense to merge MMX and 3DNow levels in the same manner as they are done for clang targets? At present a lot of the AMD targets are assuming this in X86.td but it doesn't look like its actually true.

Possibly so. I'll look into it. :)

-eric

Well, that was embarrassingly easy:

Committing to https://llvm.org/svn/llvm-project/llvm/trunk ...
M lib/Target/X86/X86.td
M lib/Target/X86/X86Subtarget.cpp
M lib/Target/X86/X86Subtarget.h
Committed r253122

:)

-eric