Fold "cns"[cns] for ROS<char>

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221

[EgorBo]

Closes#78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

[ghost]

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

Issue Details

---

Closes #78359
e.g.:

intTest()=>DoWork("D");[MethodImpl(MethodImplOptions.AggressiveInlining)]intDoWork(ReadOnlySpan<char>format){if(format.Length==1){switch(format[0]|0x20){case'a':return1;case'b':return2;case'c':return4;case'd':return8;case'e':return16;case'f':return32;}}thrownewException();}

Current codegen for Test:

; Method ConsoleApp8.C:Test():int:thisG_M000_IG01: ;; offset=0000H56pushrsi 4883EC20 subrsp,32G_M000_IG02: ;; offset=0005H 48B84023807D78020000 movrax,0x2787D802340 488B00 movrax, gword ptr [rax] 4883C00C addrax,12 0FB700 movzxrax, word ptr [rax] 83C820 oreax,32 83C09F addeax,-97 83F805 cmpeax,57746ja SHORT G_M000_IG10 8BC0 moveax,eax 488D0D63000000 learcx,[reloc @RWD00] 8B0C81 movecx, dword ptr [rcx+4*rax] 488D15CEFFFFFF leardx, G_M000_IG02 4803CA addrcx,rdx FFE1 jmprcxG_M000_IG03: ;; offset=003CH B801000000 moveax,1 EB21 jmp SHORT G_M000_IG09G_M000_IG04: ;; offset=0043H B802000000 moveax,2 EB1A jmp SHORT G_M000_IG09G_M000_IG05: ;; offset=004AH B804000000 moveax,4 EB13 jmp SHORT G_M000_IG09G_M000_IG06: ;; offset=0051H B808000000 moveax,8 EB0C jmp SHORT G_M000_IG09G_M000_IG07: ;; offset=0058H B810000000 moveax,16 EB05 jmp SHORT G_M000_IG09G_M000_IG08: ;; offset=005FH B820000000 moveax,32G_M000_IG09: ;; offset=0064H 4883C420 addrsp,32 5E poprsi C3 retG_M000_IG10: ;; offset=006AH 48B9582E82E0FA7F0000 movrcx,0x7FFAE0822E58 E84744AC5F call CORINFO_HELP_NEWSFAST 488BF0 movrsi,rax 488BCE movrcx,rsi FF153BB10800 call[System.Exception:.ctor():this] 488BCE movrcx,rsi E843509F5F call CORINFO_HELP_THROW CC int3RWD00 dd	00000037h ; case G_M000_IG03dd0000003Eh ; case G_M000_IG04dd00000045h ; case G_M000_IG05dd0000004Ch ; case G_M000_IG06dd00000053h ; case G_M000_IG07dd0000005Ah ; case G_M000_IG08; Total bytes of code: 142

New codegen for Test:

; Method ConsoleApp8.C:Test():int:this B808000000 moveax,8 C3 ret; Total bytes of code: 6

Author:	EgorBo
Assignees:	-
Labels:	area-CodeGen-coreclr
Milestone:	-

[EgorBo]

@SingleAccretion can you please take a look at the VN side when you have time, we discussed this one yesterday. For the issue with the side-effects I decided to just call gtUpdateStmtSideEffects for current statement and it worked.

[SingleAccretion]

Why are we interested in TYP_SHORT (signed) trees, since I assume this is a TP heuristic?

This shouldn't have to recompute addrVN + GetVNFunc, since the caller already did that.

[EgorBo]

@SingleAccretion can you point me where exactly caller already did it? it seems like other paths also compute it

runtime/src/coreclr/jit/valuenum.cpp

Lines 8838 to 8853 in b406c17

	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToStatic))
	{
	fldSeq = vnStore->FieldSeqVNToFieldSeq(funcApp.m_args[1]);
	offset = vnStore->ConstantValue<ssize_t>(funcApp.m_args[2]);
	// Note VNF_PtrToStatic statics are currently always "simple".
	fgValueNumberFieldLoad(tree, /* baseAddr */nullptr, fldSeq, offset);
	}
	elseif (tree->OperIs(GT_IND) && fgValueNumberConstLoad(tree->AsIndir()))
	{
	// VN is assigned inside fgValueNumberConstLoad
	}
	elseif (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) && (funcApp.m_func == VNF_PtrToArrElem))
	{
	fgValueNumberArrayElemLoad(tree, &funcApp);
	}

.

Changed to TYP_SHORT (yes, it was a TP fast-out path)

[SingleAccretion]

can you point me where exactly caller already did it? it seems like other paths also compute it

else if (vnStore->GetVNFunc(addrNvnp.GetLiberal(), &funcApp) computes it. It would be good to change this to compute the thing once like ASG numbering does.

[EgorBo]

do you mind if I leave it as is, I've just pushed a change to extract vnfunc only after TP-oriented checks. I tried to re-organize code to save these two existing lookups and didn't like the outcome, feel free to file a PR to clean it up

[SingleAccretion]

Sure.

[am11]

switch(format[0]|0x20)

Looks like with char.ToLowerInvariant() it emits an extra mov and a jmp.

+ switch (char.ToLowerInvariant(value[0]))- switch (value[0] | 0x20)

C.M2()
+ L0000: mov rcx, 0x207d38020d8+ L000a: mov rcx, [rcx]+ L000d: jmp 0x00007ff863530090- L0000: mov eax, 8- L0005: ret

and gets worse with value.ToLowerInvariant()[0]. Maybe importer can normalize them to | 0x20 equivalent for ASCII / A-Za-z values (since ToLowerInvariant() is more common than | 0x20).

[EgorBo]

@am11 good point! That jump is a tail call to TextInfo:ToLowerInvariant which is not inlined, I've pushed a change that fixes that - 369179d, e.g.:

charfoo()=>char.ToLowerInvariant('B');

Was:

; Method Prog:foo():ushort:this B942000000 movecx,66 ; 'B' FF25556B1500 tail.jmp[System.Globalization.TextInfo:ToLowerInvariant(ushort):ushort]; Total bytes of code: 11

Now:

; Method Prog:foo():ushort:this B862000000 moveax,98 ; 'b' C3 ret; Total bytes of code: 6

I think it's fine to mark those as AggressiveInlining: Invariant is folded always (inliner has no chance to know it in advance) and IsAsciiCodePoint and ToUpperAsciiInvariant are single instructions basically.

[EgorBo]

@jkotas does VM side look good to you?

[jkotas]

The VM side looks good.

[EgorBo]

@SingleAccretion can you take a look again? 🙂

As I said in some of the comments, I decided to avoid assertprop changes in this PR - so it still folds everything, but might leave nullchecks in some cases. I'll work separately (once this lands and collections are updated) to see if it's worth the effort and JIT-TP to clean them up (local runs of jit-diff state that there are not so many hits)

[SingleAccretion]

Jit side changes LGTM.

[EgorBo]

@jakobbotsch Can you please sign off the jit side (if it looks good to you)

[EgorBo]

Merging to have a new collection by Monday.
Two CI failures are unrelated because they're Mono only, e.g. iOS seems to be struggling connecting to a test device in that test (infra issue)

[jkotas]

Two CI failures are unrelated because they're Mono only

We still want to keep track of the unrelated intermittent failures to ensure that they are getting fixed: https://github.com/dotnet/runtime/blob/main/docs/pr-builds.md#what-to-do-if-you-determine-the-failure-is-unrelated

Both of the failures are known - I have added comments to the tracking issues for you.

[EgorBo]

Improvements on x64:

• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9914
• [Perf] Alpine/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#9907
• [Perf] Windows/x64: 2 Improvements on 11/21/2022 12:41:05 AM perf-autofiling-issues#10221