Description

This PR enables Profile-Guided Optimization (PGO) and Link-Time Optimization (LTO) for Windows builds (x64 and ARM64). The changes used the Linux implementation of these optimizations as guidelines. They can be used separately, but can also be used alongside each other for the best results.

PGO

PGO adds 2 new, mutually exclusive, vcbuild options:

• pgo-generate - for building an instrumented binary for generating profile data
• pgo-use - for building an optimized binary using the generated profile data

PGO is planned to be used like this:

1. vcbuild.bat pgo-generate - builds instrumented binary
2. Run workload to generate profile data
3. vcbuild.bat pgo-use - builds optimized binary

LTO

On Windows, LTCG was used for a long time. Since moving to ClangCL, LTO is an option, and this PR adds support for it. Together with adapting the legacy LTCG option (which is still available and used for release builds), there are 2 new LTO options in vcbuild. All 3 are mutually exclusive:

• ltcg - since LTCG is an MSVC-specific optimization, it is now changed to apply thin LTO, but only to the Node.js executable. This is how LTCG was applied previously.
• thin-lto - applies thin LTO to all projects (except build-time tools)
• lto - applies full LTO to all projects (except build-time tools)

Next steps

This PR simply enables using PGO and/or LTO in Windows builds, and as such, is a good starting point, but in order to capitalize on it, more work is needed in the future. Because of this, I believe these changes are safe to land, as they just enable optimizations, without forcing them anywhere. Here is a rough set of a few future steps we could take if we wanted to leverage this:

• Remove the ltcg option, and start using thin-lto for Windows builds. This is a simple change to make, but we need to investigate how it will affect build time and performance, as we do not want to make the Windows compilation job a bottleneck
• Enabling PGO in the release CI for official releases. This is a much bigger task, and should probably be separated into a few minor ones. For example, first we'd have to come up with a good workload for instrumented build, validate the benefits it can give us, and after all of that, we'd need to change the release CI build job to start using this for official releases.

Refs: #61964