Unnecessary zeroing of boxed default instances

[MichalStrehovsky]

using System;
using System.Collections.Generic;
public static class C {
    public static object M() {
        return default(KeyValuePair<String, String>);
    }
}

M gets compiled into:

; Assembly listing for method C:M():System.Object (FullOpts)
; Emitting BLENDED_CODE for X64 with AVX512 - Windows
; FullOpts code
; optimized code
; rsp based frame
; partially interruptible
; No PGO data

G_M000_IG01:                ;; offset=0x0000
       sub      rsp, 40

G_M000_IG02:                ;; offset=0x0004
       mov      rcx, 0x7FFD31850E58
       call     CORINFO_HELP_NEWSFAST
       xor      ecx, ecx
       mov      qword ptr [rax+0x08], rcx
       mov      qword ptr [rax+0x10], rcx

G_M000_IG03:                ;; offset=0x001D
       add      rsp, 40
       ret

We optimized the box into a sequence of NEWSFAST+initialize fields, realized we're doing zero init (initialization is done with a mov instead of a write barrier), but failed to realize NEWSFAST already returns a zero-initialized thing and initializing fields to zero is unnecessary.

[dotnet-policy-service]

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

[EgorBo]

There is even a more trivial example:

object Foo() => 0; // boxing zero

asm:

; Method MyClass:Foo():System.Object (FullOpts)
       sub      rsp, 40
       mov      rcx, 0x7FFB4FC6F900
       call     CORINFO_HELP_NEWSFAST
       xor      ecx, ecx
       mov      dword ptr [rax+0x08], ecx ;;; <--- redundant
       add      rsp, 40
       ret      
; Total bytes of code: 29

I presume this can be trivially fixed, but to make it more robust and handle a lot more cases we need to model memory in SSA/VN

https://llvm.org/docs/MemorySSA.html

[AndyAyersMS]

Seems possibly related to not using field seqs for the stores to boxes; if we did this I think VN's underlying memory model might "just work" and these would get dead stored. See eg #85570.

[jakobbotsch]

Seems possibly related to not using field seqs for the stores to boxes; if we did this I think VN's underlying memory model might "just work" and these would get dead stored.

#96942 tracks this -- when I looked it's not all that simple to model that "all these fields are zero" like we would need here.