Switch to ymm after zmm in genZeroInitFrameUsingBlockInit

[EgorBo]

Closes #114274

 vxorps   xmm4, xmm4, xmm4
 vmovdqu32 zmmword ptr [rsp+0x20], zmm4
-vmovdqa  xmmword ptr [rsp+0x60], xmm4
-vmovdqa  xmmword ptr [rsp+0x70], xmm4
+vmovdqu  ymmword ptr [rsp+0x60], ymm4
 vmovdqu  xmmword ptr [rsp+0x80], xmm4

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[EgorBo]

PTAL @dotnet/jit-contrib small change, a couple of diffs (only reproduces on avx512)

[Copilot]

Pull Request Overview

This PR refactors the zero-initialization of stack frames to use YMM after ZMM, consolidates loops into a single while-based approach, and replaces aligned vmovdqa with unaligned vmovdqu for YMM registers.

• Replaces two for-loops with a while-loop driven by lenRemaining
• Computes regSize dynamically via roundDownSIMDSize and chooses aligned vs. unaligned moves
• Introduces ALIGN_UP(blkSize, 16) to drive the loop and switches mov instructions

Comments suppressed due to low confidence (1)

src/coreclr/jit/codegenxarch.cpp:11261

• Add tests for block sizes not divisible by SIMD widths (e.g., sizes between 1–15, 17–31 bytes) to verify that remainders are handled correctly by this loop.

while (lenRemaining > 0)

[tannergooding]

Does simdUnalignedMovIns() get hoisted out of the loop, or will it be a lookup each time?

Is there a reason to not just always use the unaligned instruction since they're the same perf for accesses that are actually aligned?

[EgorBo]

I presume it acts as a validation of the assumption that the frame pointer is 16 bytes aligned, but not sure, I just copied it from the previous logic

[EgorBo]

/ba-g "windows-x86 Debug Libraries_CheckedCoreCLR is stuck"