xatomic.h header in VS 2017 includes <intrin0.h> instead of <intrin.h> like
before. Adding an intrin0.h header which internally includes <intrin.h> when
compiling for the Windows platform.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
This sounds like it would defeat what I'm assuming is the intended purpose of intrin0.h, which is to reduce compile time. intrin.h is kind of enormous, and the compile time problems are well-documented. We should investigate what's up with intrin0.h and implement as many builtins as we need to support it.
I agree. This currently resolves issues with building for ARM64 target using Visual Studio 2017. The missing intrinsics it complains about are already present in intrin.h. We could add those to intrin0.h too but that would duplicate. Please let me know what you think.
Yes, the "real builtin" approach seems to be best. For a recent example, D49606 added __shiftright128 as an inline function in intrin.h, but that didn't work with MSVC's STL when I moved our declaration of __shiftright128 from intrin.h to intrin0.h. This was fixed by D50907 making __shiftright128 a real builtin.
For the record, MSVC's intrin.h declares ~880 intrinsics (plus many many more from immintrin.h etc.) and it includes intrin0.h to get the declarations of ~130 intrinsics. There is no duplication - each intrinsic is declared in either the small intrin0.h or the large intrin.h. MSVC's STL then includes intrin0.h in its headers for increased throughput. We occasionally move intrinsics from intrin.h to intrin0.h as we discover that they're needed in the STL (as we've recently done for __shiftright128, _umul128, _BitScanForward[64], and _BitScanReverse[64]).