/cc @dotnet/jit-contrib as FYI, @stephentoub, @jkotas

How hard is this to fix it in the JIT?

The managed changes are very straightforward - use unsigned instead of signed integers when performing byref arithmetic. A shift-F12 on Unsafe.Add<T>(ref T, int) will quickly find interesting call sites. Somebody from the JIT side should speak to the required changes there since I didn't see any immediately obvious way to address it.

Edit for clarification: We can't just do a search-and-replace on the managed side since there are valid scenarios where a caller might have wanted to use signed byref arithmetic. But my gut tells me that the majority of call sites only ever pass non-negative values and would be eligible candidates to call the unsigned API over the signed API.

I have looked at the asm delta for Utf8Parser_Sum before and after your change. It changes movsxd rax,eax into mov eax,eax. Is it what you see as well? (I does not make any perf difference on my machine.)

// The loop from Utf8Parser_Sum
mov     rcx,qword ptr [rsi+8]
test    rcx,rcx
jne     test!My.Work()+0x3f (00007ff7`ede3226f)
xor     ebp,ebp
xor     r14d,r14d
jmp     test!My.Work()+0x47 (00007ff7`ede32277)
lea     rbp,[rcx+10h]
mov     r14d,dword ptr [rcx+8]
test    r14d,r14d
jbe     test!My.Work()+0x99 (00007ff7`ede322c9)
lea     rcx,[rsp+20h]
mov     qword ptr [rcx],rbp
mov     dword ptr [rcx+8],r14d
lea     rcx,[rsp+20h]
lea     rdx,[rsp+38h]
lea     r8,[rsp+30h]
mov     r9d,4Eh
call    System.Buffers.Text.Utf8Parser.TryParse(System.ReadOnlySpan`1<Byte>, Int32 ByRef, Int32 ByRef, Char) (00007ff7`ede31f08)
mov     eax,dword ptr [rsp+30h]
cmp     eax,r14d
ja      test!My.Work()+0xac (00007ff7`ede322dc)
sub     r14d,eax
movsxd  rax,eax // this turns into mov eax,eax with your change
add     rbp,rax
cmp     r14d,1
jb      test!My.Work()+0xb2 (00007ff7`ede322e2)
dec     r14d
inc     rbp
add     edi,dword ptr [rsp+38h]
test    r14d,r14d
ja      test!My.Work()+0x4c (00007ff7`ede3227c)
dec     ebx
test    ebx,ebx
jg      test!My.Work()+0x2f (00007ff7`ede3225f)

@jkotas - I also hacked the JIT to eliminate the mov entirely. Basically, I "fixed" https://github.com/dotnet/coreclr/issues/23666 and reran the benchmarks to get the numbers you see here. This PR doesn't have that hack (because it was nowhere near production-quality).

I don't think there is an easy fix in the jit. There are a bunch of inter-related issues we should tackle in a coordinated fashion:

• Allow cast containment ([WIP] Enable cast operand containment #12676, responding to #12595, waiting on Sort out ARM load/store instruction size issues #20126)
• Don't sign extend for array.len, span.len, and known in-bounds indices when implicit zero extension is available for a 32 bit load (as it is on x64 and arm64). One prototype here: https://github.com/dotnet/coreclr/issues/23127#issuecomment-471040829
• Don't explicitly zero extend values that are already implicitly zero extended (in the spirit of JIT: Suppress emitting same-reg zero extending move #22454 but done earlier when we have better producer-consumer connections).
• IV widening for 64 bit targets (#9179, [WIP] Eliminate array/Span index sign-extension #21553)

Looks like this isn't needed since per Andy's comments there are tracking issues that will improve the JIT all-around. Closing this.