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

[Max Winkler via llvm-commits]

MaxEW707 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.
Pretty much all the big hitters, string/vector/map/algorithm, includes `<xmemory>` which includes `<limits>` which includes `<intrin[0].h>`.
The test file used looked as follows to simulate some common stl includes.
```
#include <map>
#include <vector>
#include <memory>
```

clang-cl 16 frontend took ~190ms to parse those 3 headers. `intrin.h` took ~32ms to parse.

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.

It is known that `immintrin.h` and `x86intrin.h` being the everything header definitely makes it an **expensive** include.
I don't need to compile any project to know that include time difference will be felt by any code that uses STL.

MSVC STL ships with each compiler upgrade. VS has a separate dir for each installed msvc, `VC\Tools\MSVC\14.38.33130` for MSVC 1938, and each installed compiler has a specific version of msvc stl shipped with it under, `VC\Tools\MSVC\[version]\include`.
Only one version of clang-cl is shipped with VS at a time and it will always point to the latest `VCToolsDir` via the clang driver unless clang is passed an explicit dir on the command line by the user.
For example VS2022 17.7 upgraded from clang-cl 15 to clang-cl 16. From that point on-wards only clang-cl 16 exists on disk in your VS install.
That seems to correspond to what was said here, https://github.com/microsoft/STL/pull/4282#discussion_r1441191186, every shipped version of MSVC STL supports only the latest compilers provided by VS.

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.

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