Build the STL with only /O2, not /Os

[StephanTLavavej]

Fixes #2108.

The STL (and indeed the entire internal "crt" directory) was being built with /O2 /Os. I'm convinced that this was unintentional for a really silly reason (MSBuild made it hard to see that there was a global default for /Os, which the compiler DLLs like c1xx.dll and c2.dll overrode, but the library DLLs missed). When our build system / compiler options were ported to CMake, the usage of /O2 /Os looked way more intentional than it was.

I loathe /Os and the old "small is fast" heuristic. The STL expects a lot of inlining for performance, so /Os is very hostile to our code. You know what's a better heuristic? "Fast is fast." Give just /O2 to the compiler and let it figure out what's fastest. (Caches are also massively bigger than decades ago, so an obsessive focus on code size is not nearly as important.)

Of course, removing /Os will increase the size of our DLLs. However, the effect isn't massive, and we've made offsetting improvements. Here are my measurements:

DLL Size (Bytes)	main x64	main x86	main ARM64
msvcp140_oss.dll	519,168	411,136	615,424
msvcp140_1_oss.dll	13,824	11,776	14,336
msvcp140_2_oss.dll	360,448	353,280	345,088
msvcp140_atomic_wait_oss.dll	156,672	154,624	151,552
msvcp140_codecvt_ids_oss.dll	8,704	8,192	9,728
Total	1,058,816	939,008	1,136,128

DLL Size (Bytes)	PR x64	PR x86	PR ARM64
msvcp140_oss.dll	653,312	589,312	743,424
msvcp140_1_oss.dll	13,824	11,776	14,336
msvcp140_2_oss.dll	406,528	381,440	366,592
msvcp140_atomic_wait_oss.dll	157,696	156,160	152,576
msvcp140_codecvt_ids_oss.dll	8,704	8,192	9,728
Total	1,240,064	1,146,880	1,286,656

Arch	Size Increase
x64	1.171
x86	1.221
ARM64	1.132

In my opinion these are reasonable increases. (Reversing the status quo, if we were currently being built with /O2, we would not be interested in pessimizing our codegen to save a bit of space here with /O2 /Os.)

And as for offsetting improvements, while the STL has had a tendency to grow over time as more code is added, we've also been able to remove a lot of code by increasing our OS baseline up to Win10, plus deliberate changes like #5836. (For the VCRedist size itself, I removed entire megabytes by dropping the Win7/8/8.1 MSUs in VS 2026 / MSVC Build Tools 14.50.) See #2108 (comment) for my most recent DLL size archaeology.

So while removing /Os will increase DLL sizes, I believe that the impact is acceptable. For example, looking at the original STL DLL, it was 633,152 bytes in VS 2015 Update 3. That decreased to 532,048 bytes in the latest MSVC Build Tools 14.51 Preview, and this PR increases it to 653,312 - so, a little bigger than it was historically, but essentially paid for by our improvements over the years.

[davidmrdavid]

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo. Please notify me if any further changes are pushed, otherwise no action is required.