MSVC Backend Updates in Visual Studio 2022 version 17.2
Chris Pulido
In Visual Studio 2022 version 17.2 we have continued to improve the C++ backend with new features, new and improved optimizations, build throughput improvements, and better security. Here is a list of improvements for you to review.
- OpenMP: The
taskdirective as defined by OpenMP 3.1 is supported for-openmp:llvm, including all the clauses. Note that the compiler does not yet support `task` clauses added in later versions of OpenMP. See more details in OpenMP Task Support for C++ in Visual Studio. - Implemented Intel intrinsic functions for the AVX512-FP16 instruction set extension. More information about these functions can be found on the Intel Intrinsics Guide.
- Implemented Intel intrinsic functions
_castf32_u32,_castf64_u64,_castu32_f32, and_castu64_f64Â to cast between floating point values and integer values without conversion on x64 and x86. More information about these functions can be found on the Intel Intrinsics Guide. - New ARM64 compiler flags:
/Zc:arm64-aliased-neon-types-and/Zc:arm64-aliased-neon-types. When you pass/Zc:arm64-aliased-neon-types-tocl.exe, the compiler will treat NEON intrinsic types as distinct types for ARM64 as defined by the Procedure Call Standard for the Arm 64-bit Architecture, which is consistent with Clang and GCC. This flag is opt-in, so ARM64 NEON intrinsic code that compiled with previous versions of MSVC will still compile when you upgrade./Zc:arm64-aliased-neon-types (without the minus sign at the end) is the default behavior.- For example, consider two function declarations,
void foo(float32x4_t)andvoid foo(int32x4_t). By default, MSVC considers these two the same declaration, and attempting to define them both would lead to a multiple definition error. With/Zc:arm64-aliased-neon-types-, MSVC will treat them as Clang and GCC would.
- For example, consider two function declarations,
- New ARM64 compiler flags:
/arch:armv8.0and/arch:armv8.1. These new flags allow the compiler to generate instructions that were introduced and required by the specified architecture extension. `/arch:armv8.0` is the current default behavior and is the same as if you didn’t specify it. In 17.2,/arch:armv8.1allows the_Interlocked*intrinsic functions to use the appropriate atomic instruction that was introduced with the ARMv8.1 extension, FEAT_LSE. - New and improved optimizations
- The C standard library functions
log2andlog2fhave been implemented as compiler intrinsic functions on x64 and ARM64. This allows the compiler to perform optimizations withlog2andlog2funder/fp:fast x64 and ARM64. - Improved auto-vectorizer loop recognition. The auto-vectorizer now recognizes the average pattern and more cases of decrementing induction variables.
- More peephole optimizations for multiple targets.
- Improved load/store pairing on ARM64.
- The C standard library functions
- ARM64EC
- Compiler flags incompatible with the
/arm64ECflag are now rejected. This includes all CLR flags,/Gy-, and/Gw-. - Added the
/MACHINE:ARM64ECflag tolink.exe, and removed it fromlib.exe. Forlib.exe, you should specify/MACHINE:ARM64X. - When
/arm64ECis passed tocl.exeandcl.exealso invokeslink.exe,/MACHINE:ARM64ECwill be passed by default tolink.exe.
- Compiler flags incompatible with the
Do you want to experience the new improvements of the C++ backend? Please download the latest Visual Studio 2022 and give it a try! Any feedback is welcome. We can be reached via the comments below, Developer Community, and Twitter (@VisualC)
Light
Dark
1 comment
Thanks for the update, it’s been a long time coming.
That said, after reading a recent reddit thread about this very topic, I hope the above is just a start of what’s to come.
I’d hope that as backend improvements are committed, said PR’s would have evidence of the improvements in their descriptions. Descriptions that could perhaps just be copy/pasted into an update like this in the future.
Benchmark timings, assembly diffs of before and after, examples of code size improvements, examples of how the new auto-vectorization can recognize a given loop etc. Those would be very useful to see here. The C# guys, c freakin sharp, are eating much better than us over here still.