[PATCH] D24330: Add some MS aliases for existing intrinsics

[Reid Kleckner via cfe-commits]

rnk added inline comments.

================
Comment at: include/clang/Basic/BuiltinsX86.def:304
@@ -303,2 +303,3 @@
 TARGET_BUILTIN(__builtin_ia32_ldmxcsr, "vUi", "", "sse")
+TARGET_BUILTIN(_mm_setcsr, "vUi", "", "sse")
 TARGET_BUILTIN(__builtin_ia32_stmxcsr, "Ui", "", "sse")
----------------
rsmith wrote:
> majnemer wrote:
> > rnk wrote:
> > > Part of the idea behind the Intel *mmintrin.h headers is that they define symbols outside of the implementor's namespace. Users should be able to write code that uses these _mm_* names if they don't include those headers. Having this builtin always be available on x86 makes that impossible.
> > > 
> > > That said, I can see that winnt.h uses these directly, rather than including xmmintrin.h, so we need them to be builtins in MSVC mode, and it's annoying to have them sometimes be builtins and sometimes be functions.
> > We could have the header file use a pragma which turns the _mm intrinsics on along the same lines as `#pragma intrinsic`.  For MSVC compat, we could treat them as-if they were enabled by some similar mechanism.
> Names starting with an underscore are reserved to the implementation for use in the global namespace. Also, we declare these lazily, on-demand, only if name lookup would otherwise fail, so (outside of odd SFINAE cases in C++) this shouldn't affect the meaning of any valid programs. While I find it distasteful to model these as builtins, the only significant problem I see here is that we'll accept non-portable code that forgets to include the right header if we do so.
> 
> Perhaps we could model this somewhat similarly to `LIBBUILTIN`, so that we allow use of the builtin without a declaration, but produce a diagnostic about the missing `#include` when we do so?
+1 for doing something like LIBBUILTIN


https://reviews.llvm.org/D24330