Use wmemset for fill optimization

[AlexGuteniev]

Towards #3167

Will look into vectorization of 32 and 64 bit types if this passes.

[AlexGuteniev]

⚠️ Possibly this should not be merged

See #3642

[StephanTLavavej]

If the compiler can perform this optimization, I'd prefer to avoid merging this, and potentially even remove the 1-byte memset optimization. (The metaprogramming has a minor throughput cost but a major code complexity cost - we've put a lot of energy into maintaining its correctness. I'm not too concerned about regressing non-optimized debug mode perf by returning to classic loops here.)

Marked as "decision needed" so we can talk about this on Wednesday.

[AlexGuteniev]

and potentially even remove the 1-byte memset optimization

There's even further simplification option: remove multibyte memset optimization. The compiler is still able to insert memset if it is able to propagate compile time known value. However, if zero constant is not propagated, sure the compiler does not insert the branch.

On the other hand, the previously discussed direction for #3167 is to make c32memset and c64memset, which the compiler does not insert automatically, so they could have made some real gain. Well, unless the compiler will extend its automatic memset and rep stosw insertion further, I've created DevCom-10334038 for that.

[StephanTLavavej]

We talked about this at the weekly maintainer meeting and we concluded:

• Because the compiler handles the 2-byte case, expanding the STL's metaprogramming (in an already complicated area) to call wmemset doesn't appear to be valuable enough to be worth the risk
• The compiler should be enhanced to handle 4-byte and 8-byte cases (thanks for filing the DevCom issue! 😻)
• In the long term, we might be interested in removing the 1-byte memset metaprogramming in the STL, but only if we can comprehensively confirm that the compiler emits equivalent (or better) codegen (with optimizations enabled). Importantly, we'd like to make sure that this happens even for user-defined contiguous iterators that don't participate in iterator unwrapping (as @strega-nil-ms observed).
  • The _Fill_memset_is_safe optimization is intertwined with the similar-but-different _Fill_zero_memset_is_safe optimization, and it occurs frequently enough in the STL that attempting to remove _Fill_memset_is_safe could be invasive and potentially destabilizing; although this could be possible, we're not super eager to make such a change any time soon.

[AlexGuteniev]

In the long term, we might be interested in removing the 1-byte memset metaprogramming in the STL, but only if we can comprehensively confirm that the compiler emits equivalent (or better) codegen (with optimizations enabled). Importantly, we'd like to make sure that this happens even for user-defined contiguous iterators that don't participate in iterator unwrapping (as @strega-nil-ms observed).

• The _Fill_memset_is_safe optimization is intertwined with the similar-but-different _Fill_zero_memset_is_safe optimization, and it occurs frequently enough in the STL that attempting to remove _Fill_memset_is_safe could be invasive and potentially destabilizing; although this could be possible, we're not super eager to make such a change any time soon.

I think it would be best to eventually remove both of the optimizations, as _Fill_zero_memset_is_safe is even less useful currently.