Details
- Reviewers
compnerd majnemer thakis rnk rsmith - Commits
- rG727ab8a80346: Add some MS aliases for existing intrinsics
rGae3fb3113ffc: Add some MS aliases for existing intrinsics
rC281540: Add some MS aliases for existing intrinsics
rC281375: Add some MS aliases for existing intrinsics
rL281540: Add some MS aliases for existing intrinsics
rL281375: Add some MS aliases for existing intrinsics
Diff Detail
Event Timeline
+Richard for ideas on how to navigate the intel intrinsics
include/clang/Basic/BuiltinsX86.def | ||
---|---|---|
304 | 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. |
include/clang/Basic/BuiltinsX86.def | ||
---|---|---|
304 | 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. |
include/clang/Basic/BuiltinsX86.def | ||
---|---|---|
304 | 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? |
include/clang/Basic/BuiltinsX86.def | ||
---|---|---|
304 | +1 for doing something like LIBBUILTIN |
test/Sema/implicit-intel-builtin-decl.c | ||
---|---|---|
4 ↗ | (On Diff #70926) | Can you add a C++ test? I think you'll get "undeclared identifier '_mm_getcsr'" instead of this helpful diagnostic. |
test/Sema/implicit-intel-builtin-decl.c | ||
---|---|---|
4 ↗ | (On Diff #70926) | This diagnostic works also in C++, although that's not the case with _byteswap functions - if they are LIBBUILTINs, the C++ diagnostic doesn't work, and LANGBUILTINs doesn't have header dependencies. I can create another thing like TARGET_HEADER_BUILTIN, but I don't know if that's a good idea. |
lgtm after merging the test back.
test/Sema/implicit-intel-builtin-decl.c | ||
---|---|---|
4 ↗ | (On Diff #70926) | OK, it seems fine as is. Given that there are no diagnostic differences, I would suggest copy-pasting the RUN line at the top of this file and adding -x c++ to avoid duplicating the whole test. |
xmmintrin.h and emmintrin.h broke compilation when included inside extern "C++" block
lgtm We could define a macro that conditionally expands to extern "C", but then we'd have to undef it, and that seems like no good.
include/clang/Basic/Builtins.h | ||
---|---|---|
142 ↗ | (On Diff #71271) | should the doxygen comment start with /// here ? |
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.