Suboptimal stack zeroing on AVX512

[pentp]

When compiling for AVX512 RyuJIT uses vmovdqu32 to efficiently zero 64 bytes at a time, but it does not use 32 byte zeroing like on AVX2 and falls back straight to 16 byte zeroing for remaining zeroing needs.

Sample repro:

sub      rsp, 168
vxorps   xmm4, xmm4, xmm4
vmovdqu32 zmmword ptr [rsp+0x20], zmm4
vmovdqa  xmmword ptr [rsp+0x60], xmm4 ; this should be vmovdqu ymmword ptr [rsp+0x60], ymm4
vmovdqa  xmmword ptr [rsp+0x70], xmm4 ; this could be omitted then
vmovdqa  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.

[JulieLeeMSFT]

CC @dotnet/avx512-contrib.

[pentp]

While the fix to use less instructions to zero the buffer on AVX512 should be relatively straightforward, I noticed that there is potential to reduce the number of instructions even more on most target platforms by zeroing a bit more of the reserved stack space than strictly necessary - this might need some measurement first to be sure it will not cause any regressions due to the extra writing, but the savings on code size and instruction count would probably make it faster.

The same repro for example reserves 168 bytes (0xA8) of stack space and then zeroes it from 0x20 to 0x98 (120 bytes), but if it zeroed 8 bytes more, it could collapse it into just 2 instructions on AVX512 and 4 instructions on AVX2.

[tannergooding]

I don't think it's worth over allocating here to save 1-3 instructions. There's additional risk and complexities involved and anything involving writing past the end of a known buffer space is dangerous.

If we did want to save in such a scenario, it'd be better to make the last write simply backtrack the address instead which always gives the least number of writes required, doesn't require extra space, etc. That is to say, for any number of bytes from [1, MaxSimdVectorSize * 2] you never need more than 2 writes. For anything greater than this, you need no more than (Size / MaxSimdVectorSize) + 1 writes.

For example, something like 95 bytes involves the following, which is two writes and keeps the allocations to a minimum:

xorps xmm0, xmm0, xmm0    ; all bits are zeroed for ymm0 and zmm0 as well
movups [addr], zmm0
movups [addr + 31], zmm0

There is a 1 cycle penalty for the latter write being misaligned, but this is exactly what memset and memcpy do for such sizes as well. They pay the misalignment penalty because its better than branching or doing extra writes, etc; and we don't want to have to allocate up to an extra 63 bytes per method just to save the 1 cycle penalty.

[pentp]

I don't think it's worth over allocating here to save 1-3 instructions. There's additional risk and complexities involved and anything involving writing past the end of a known buffer space is dangerous.

I'm not suggesting writing outside the stack boundary or allocating more stack, just zeroing a bit more of the stack space already reserved by the method (it's very common that only part of the stack is zeroed).

There is a 1 cycle penalty for the latter write being misaligned, but this is exactly what memset and memcpy do for such sizes as well. They pay the misalignment penalty because its better than branching or doing extra writes, etc; and we don't want to have to allocate up to an extra 63 bytes per method just to save the 1 cycle penalty.

I'm also not suggesting backtracking the last write for the reasons you mentioned, only opportunistically expanding the zeroed part of the stack space reserved by the method when it would reduce number of instructions - the only theoretical downside here would be the additional bytes written.

[pentp]

For example for the original repro the result would be on AVX512:

sub      rsp, 168
vxorps   xmm4, xmm4, xmm4
vmovdqu32 zmmword ptr [rsp+0x20], zmm4
-vmovdqa  xmmword ptr [rsp+0x60], xmm4
-vmovdqa  xmmword ptr [rsp+0x70], xmm4
-vmovdqa  xmmword ptr [rsp+0x80], xmm4
-xor      eax, eax
-mov      qword ptr [rsp+0x90], rax
+vmovdqu32 zmmword ptr [rsp+0x60], zmm4

And on AVX2:

sub      rsp, 168
vxorps   xmm4, xmm4, xmm4
vmovdqu  ymmword ptr [rsp+0x20], ymm4
vmovdqu  ymmword ptr [rsp+0x40], ymm4
vmovdqu  ymmword ptr [rsp+0x60], ymm4
-vmovdqa  xmmword ptr [rsp+0x80], xmm4
-xor      eax, eax
-mov      qword ptr [rsp+0x90], rax
+vmovdqu  ymmword ptr [rsp+0x80], ymm4

[tannergooding]

That's still writing "out of bounds" with regards to the local in question; so there is risk there.

What I was suggesting was that simply backtracking and taking the 1 cycle penalty is safer, avoids the extra register, etc. It's what the core memory CRT functions all do.