This is an archive of the discontinued LLVM Phabricator instance.

[Headers] [MS] Add intrin0.h
Needs ReviewPublic

Authored by azharudd on Oct 30 2018, 4:49 PM.

Details

Reviewers
rnk
mgrang
Summary

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.

Diff Detail

Repository
rC Clang

Event Timeline

azharudd created this revision.Oct 30 2018, 4:49 PM
rnk added a comment.Oct 30 2018, 4:57 PM

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.

In D53912#1281584, @rnk wrote:

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.

rnk added a subscriber: STL_MSFT.Nov 2 2018, 2:04 PM

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.

I see that more intrinsics are being added as builtins in D54046. I think that's a good future direction. We should do our best not to add new headers to shadow CRT and SDK headers anymore. +@STL_MSFT

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]).