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