[compiler-rt] [lldb] [llvm] [openmp] [lld] [mlir] [clang-tools-extra] [libcxx] [clang] [flang] [clang] Add `intrin0.h` header to mimic `intrin0.h` used by MSVC STL for clang-cl (PR #75711)

[Reid Kleckner via cfe-commits]

rnk wrote:

> > I would like some measurements so we can compare build times on Windows.
> 
> I took some benchmarks with `-ftime-trace` on the parse times with and without this change. 
> ...
> clang-cl built with this PR frontend took ~1368ms to parse. `intrin.h` took ~969ms to parse. Most of that time is from `<x86intrin.h>` as expected. `intrin0.h` took ~2ms to parse.

Thank you for remeasuring! Roughly speaking, anyone using a clang from between the time that this PR lands and they update the MSVC STL will experience a 1 second slowdown in every compilation that didn't already use `immintrin.h`.

> We have some options. I am fine with whatever the consensus is as long as I can move this over the finish line.
> 
> 1. Users who upgrade clang-cl before MSVC STL officially supports the new version of clang-cl will suffer slower builds.
>    I would classify this as an unsupported config since once VS ships with support for the new clang-cl, intentionally building against an older `VCToolsDir` will also incur the include overhead. Up to you guys if view this as an unsupported config.
> 2. Add a config define that users can define to enable the old behaviour in the interim. Once MSVC STL supports the new version of clang-cl we can remove this config define in the next release.
> 3. Release clang with `intrin0.h`. Get a change into MSVC STL. Wait for MSVC STL release. Release another clang with `intrin.h` changes. I am not well versed on what changes clang allows in patch or minor releases but this feels like it would have a long lag time before clang-cl can become usable for us.

I think I favor 2. Users (Chromium included) use recent versions of Clang that are not vendored by Microsoft. Users can also use the LLVM OSS releases. I think most users probably won't notice the compile time regression, and it will silently go away the next time the update MSVC, but if they do and they care (and this should be in the release notes), it would be nice to have a macro to get the old behavior. There may also be users permanently targeting old MSVC STL versions and they will never get the update to use `intrin0.h`, but I believe fewer people do this since MSVC stabilized the standard library ABI.

It would be nice to factor out the `!defined(__SCE__) || __has_feature(modules)` condition into something more descriptive like `__CLANG_ENABLE_ALL_INTEL_INTRIN`, to clean up the conditional includes regardless of whether we add this opt-out flag.

https://github.com/llvm/llvm-project/pull/75711