Jit double zeros

[benaadams]

Given sharplab

using System.Buffers;
using System.Runtime.CompilerServices;

public class C 
{
    public void M() 
    {
        var amb = AsyncValueTaskMethodBuilder<ReadResult>.Create();
    }
}

public readonly struct ReadResult
{
    internal readonly ReadOnlySequence<byte> _resultBuffer;
    internal readonly int _resultFlags;
}

The Jit zeros in the preamble with rep stosd and then zeros in the body with vmovdqu

L0000: push rdi
L0001: push rsi
L0002: sub rsp, 0x38
L0006: vzeroupper
L0009: mov rsi, rcx
L000c: lea rdi, [rsp+0x8]           ;
L0011: mov ecx, 0xc                 ;
L0016: xor eax, eax                 ;
L0018: rep stosd                    ; clear stack
L001a: mov rcx, rsi
L001d: lea rax, [rsp+0x8]           ;
L0022: vxorps xmm0, xmm0, xmm0      ; 
L0026: vmovdqu [rax], xmm0          ; 
L002a: vmovdqu [rax+0x10], xmm0     ; 
L002f: vmovdqu [rax+0x20], xmm0     ; clear stack again
L0034: add rsp, 0x38
L0038: pop rsi
L0039: pop rdi
L003a: ret

Would it be possible for the Jit to skip the second set of zeroing given its already zeroed the stack at the start?

category:cq
theme:prolog-epilog
skill-level:expert
cost:medium

[AndyAyersMS]

cc @erozenfeld

[benaadams]

A more specific/common example is async, for example ReadResults in System.IO.Pipelines; which may be more problematic as currently the C# statemachine generation inserts the saving of parameters before the call to .Create and assign, which does the second zeroing.

using System.IO.Pipelines;

public async ValueTask<ReadResult> OuterMethod(object o)
{
    return await InnerMethod(o);
    
    static async ValueTask<ReadResult> InnerMethod(object o) 
    {
        return default;
    }
}

G_M16490_IG01:
    push     rdi
    push     rsi
    sub      rsp, 136
    vzeroupper 
    mov      rsi, rcx                 ;
    lea      rdi, [rsp+20H]           ;
    mov      ecx, 26                  ;
    xor      rax, rax                 ;
    rep stosd                         ; zero
    mov      rcx, rsi
    mov      rsi, rdx
						;; bbWeight=1    PerfScore 30.00
G_M16490_IG02:
    mov      gword ptr [rsp+20H], r8          ; save param
    xor      ecx, ecx                         ; re-zero
    vxorps   xmm0, xmm0                       ; re-zero
    vmovdqu  xmmword ptr [rsp+30H], xmm0      ; re-zero
    vmovdqu  xmmword ptr [rsp+40H], xmm0      ; re-zero
    mov      qword ptr [rsp+50H], rcx         ; re-zero
    mov      dword ptr [rsp+28H], -1
    lea      rcx, [rsp+20H]
    call     System.Runtime.CompilerServices.AsyncMethodBuilderCore:Start(byref)
    lea      rcx, bword ptr [rsp+30H]
    mov      rdx, rsi
    call     System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[ReadResult][System.IO.Pipelines.ReadResult]:get_Task():System.Threading.Tasks.ValueTask`1[ReadResult]:this
    mov      rax, rsi
						;; bbWeight=1    PerfScore 9.08
G_M16490_IG03:
    add      rsp, 136
    pop      rsi
    pop      rdi
    ret      
						;; bbWeight=1    PerfScore 2.25

[erozenfeld]

I'll investigate.

[erozenfeld]

#31677 reduces the code for the first example to a single ret instruction.

The second one is harder to deal with. We are very conservative with address-exposed locals and don't try to figure out any liveness information for them. I'm trying to find an inexpensive way to do better at least in some simple cases.

[benaadams]

@erozenfeld would this roslyn change help, or not make any difference? dotnet/roslyn#41253 (comment)

[benaadams]

Or would changing it to move all the zeroing above that first assignment to non-zero (which would be a much more complex refactoring in Roslyn)

[erozenfeld]

Neither of these two changes will help the jit. It has trouble with double initialization in much simpler cases, e.g., #1007. In your example there are 3 blockers for the jit. Any of them will currently result in double zero-initialization.

1. The local is marked as address-exposed and the jit doesn't do any liveness tracking for such locals.
   Here the explicit initialization happens in the first basic block so maybe we can special-case this somehow.
2. We are initializing a field of struct type. There is some unfinished work on better morphing such fields that could help here, e.g.,

   runtime/src/coreclr/src/jit/lclmorph.cpp

   Line 1012 in 2cf4433

   // TODO-ADDR: Add TYP_STRUCT support to LCL_FLD.

3. The struct has gc fields. We are very conservative in initializing such structs in the prolog:

   runtime/src/coreclr/src/jit/codegencommon.cpp

   Lines 4636 to 4640 in 8bd94d1

   	if ((!varDsc->lvTracked || (varDsc->lvType == TYP_STRUCT)) && varDsc->lvOnFrame &&
   	(!varDsc->lvIsTemp || varDsc->HasGCPtr()))
   	{
   	varDsc->lvMustInit = true;