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? https://reviews.llvm.org/D24330 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
