Inefficient register allocation in simple method which dereferences a span

[GrabYourPitchforks]

    public static int DerefAndReturn(int index, ReadOnlySpan<int> span) {
        int retVal = default;
        
        if ((uint)index < (uint)span.Length)
        {
            retVal = span[index];
        }
        
        return retVal;
    }

C.DerefAndReturn(Int32, System.ReadOnlySpan`1<Int32>)
    L0000: mov rax, [rdx]
    L0003: mov edx, [rdx+0x8]
    L0006: xor r8d, r8d
    L0009: cmp ecx, edx
    L000b: jae L0014
    L000d: movsxd r8, ecx
    L0010: mov r8d, [rax+r8*4]
    L0014: mov eax, r8d
    L0017: ret

In this code sample which utilizes a "single return from function" pattern, the local retVal is stored in the r8d register instead of the eax register. This necessitates an additional mov instruction near the end of the method (L0014) to get the result into the correct return register. By using r8 to hold the span reference and eax to hold the return value, we can eliminate this instruction and reduce the size of the code gen.

The movsxd instruction is also unnecessary and can be replaced with a simpler mov instruction: that's being tracked by https://github.com/dotnet/coreclr/issues/23127.

category:cq
theme:register-allocator
skill-level:expert
cost:large

[BruceForstall]

@CarolEidt

[CarolEidt]

The issue here is that the register allocator is not looking far enough ahead, so it uses rax for the pointer field of the span, and then it is not available when it sets retVal to zero. This could potentially be addressed by pre-allocating lclVars according to their preferenced registers, as suggested in #8019, but that is a non-trivial task to undertake.

[dotnet-policy-service]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of our issue cleanup automation.

[dotnet-policy-service]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.