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

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 8 11:18:08 PDT 2016

rsmith 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")
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?


More information about the cfe-commits mailing list