improve zero-init code for x64.

[sandreenko]

For sequences of zero-inits like:

        long l1 = 0;
        long l2 = 0;
        long l3 = 0;
        long l4 = 0;

on x64 we would generate:

IN000e: 000038 xor      r13d, r13d
IN000f: 00003B mov      qword ptr [rsp+58H], r13
IN0010: 000040 xor      ecx, ecx
IN0011: 000042 mov      qword ptr [rsp+50H], rcx
IN0012: 000047 xor      ecx, ecx
IN0013: 000049 mov      qword ptr [rsp+48H], rcx
IN0014: 00004E xor      ecx, ecx
IN0015: 000050 mov      qword ptr [rsp+40H], rcx
IN0016: 000055 xor      ecx, ecx
IN0017: 000057 mov      qword ptr [rsp+38H], rcx
IN0018: 00005C xor      ecx, ecx
IN0019: 00005E mov      qword ptr [rsp+30H], rcx
IN001a: 000063 xor      ecx, ecx
IN001b: 000065 mov      qword ptr [rsp+28H], rcx
IN001c: 00006A xor      ecx, ecx

and for sequences like:

        ManyShorts s = GetManyShorts(); // a struct with many shorts
        s.l1 = 0;
        s.l2 = 0;
        s.l3 = 0;
        s.l4 = 0;
        s.l5 = 0;

we would generate:

IN0003: 000027 mov      word  ptr [rsp+20H], 0
IN0004: 00002E mov      word  ptr [rsp+22H], 0
IN0005: 000035 mov      word  ptr [rsp+24H], 0
IN0006: 00003C mov      word  ptr [rsp+26H], 0
IN0007: 000043 mov      word  ptr [rsp+28H], 0
IN0008: 00004A mov      word  ptr [rsp+2AH], 0

when a good CQ would be to zero one register and reuse it after, like:

IN000e: 000038 xor      ecx, ecx
IN000f: 00003B mov      qword ptr [rsp+58H], rcx
IN0011: 000042 mov      qword ptr [rsp+50H], rcx
IN0013: 000049 mov      qword ptr [rsp+48H], rcx
IN0015: 000050 mov      qword ptr [rsp+40H], rcx
IN0017: 000057 mov      qword ptr [rsp+38H], rcx
IN0019: 00005E mov      qword ptr [rsp+30H], rcx
IN001b: 000065 mov      qword ptr [rsp+28H], rcx

maybe CSE or GTF_REUSE_REG_VAL can help with it.

The full test:
Program.txt
The jitdumps:
example.Test4.txt
example.Test3.txt

category:cq
theme:zero-init

[sandreenko]

PTAL @kunalspathak , cc @dotnet/jit-contrib
the issue is similar to #52269 but is xarch specific.

[kunalspathak]

Thanks @sandreenko . I will look into it.

[EgorBo]

maybe CSE

I guess we intentionally avoid CSE for integer constants so lowering/codegen can apply more potential optimizations (or use imm)

[sandreenko]

I guess we intentionally avoid CSE for integer constants so lowering/codegen can apply more potential optimizations (or use imm)

CSE has an existing mechanism of counting the number of uses(N) so it can decide if N > 10 then create a local, put the value into a reg, and use it from there instead of imm.

[SingleAccretion]

Some related cases:

1. vxorpsed registers are not reused in some cases: sharplab.
2. Floating-point locations can be zeroed via integer registers: sharplab.

[EgorBo]

Some related cases:

1. vxorpsed registers are not reused in some cases: sharplab.

I'd say the repro is too exotic, and it works fine when both args of the same width

2. Floating-point locations can be zeroed via integer registers: sharplab.

This one is interesting, I guess it's indeed better to use mov [reg], 0

[kunalspathak]

CSE has an existing mechanism of counting the number of uses(N) so it can decide if N > 10 then create a local, put the value into a reg, and use it from there instead of imm.

Currently, CSE for constants is OFF by default for xarch -

runtime/src/coreclr/jit/jitconfigvalues.h

Lines 336 to 340 in b3278ca

	// Default 0, enable the CSE of Constants, including nearby offsets. (only for ARM64)
	// If 1, disable all the CSE of Constants
	// If 2, enable the CSE of Constants but don't combine with nearby offsets. (only for ARM64)
	// If 3, enable the CSE of Constants including nearby offsets. (all platforms)
	// If 4, enable the CSE of Constants but don't combine with nearby offsets. (all platforms)