C# compiler generates highly suboptimal code for compound assignments with struct ref variables

[uio139021]

Description

When working on my program performance optimization and inspecting the generated code, I came across the following issue. Here is a small piece of C# code and what it gets compiled into:
`
S s = default;

ref int r = ref s.i;

r += 1;
r = r + 1;

ref S rs = ref s;

rs.i += 1; // this line generates some stupid machine code (esp. 'cmp' opcode)
rs.i = rs.i + 1; // while this line compiles perfectly

s.i += 1; // this allocates a redundant var on stack
s.i = s.i + 1; // ok

public struct S
{
public int i;
}
`

The Disassembly output shows this:
`
ref int r = ref s.i;
00007FF9DC807164 lea rcx,[rbp+48h]
00007FF9DC807168 mov qword ptr [rbp+40h],rcx

r += 1;
00007FF9DC80716C mov rcx,qword ptr [rbp+40h]
00007FF9DC807170 inc dword ptr [rcx]
r = r + 1;
00007FF9DC807172 mov rcx,qword ptr [rbp+40h]
00007FF9DC807176 inc dword ptr [rcx]

ref S rs = ref s;
00007FF9DC807178 lea rcx,[rbp+48h]
00007FF9DC80717C mov qword ptr [rbp+38h],rcx

rs.i += 1; // this line generates some stupid machine code (esp. 'cmp' opcode)
00007FF9DC807180 mov rcx,qword ptr [rbp+38h]
00007FF9DC807184 cmp byte ptr [rcx],cl
00007FF9DC807186 mov rcx,qword ptr [rbp+38h]
00007FF9DC80718A mov qword ptr [rbp+30h],rcx
00007FF9DC80718E mov rcx,qword ptr [rbp+30h]
00007FF9DC807192 inc dword ptr [rcx]
rs.i = rs.i + 1; // while this line compiles perfectly
00007FF9DC807194 mov rcx,qword ptr [rbp+38h]
00007FF9DC807198 inc dword ptr [rcx]

s.i += 1; // this allocates a redundant var on stack
00007FF9DC80719A lea rcx,[rbp+48h]
00007FF9DC80719E mov qword ptr [rbp+28h],rcx
00007FF9DC8071A2 mov rcx,qword ptr [rbp+28h]
00007FF9DC8071A6 inc dword ptr [rcx]
s.i = s.i + 1; // ok
00007FF9DC8071A8 mov ecx,dword ptr [rbp+48h]
00007FF9DC8071AB inc ecx
00007FF9DC8071AD mov dword ptr [rbp+48h],ecx
`

It follows then, that using compound assignment ops with struct refs leads to sub-optimal code compared to equivalent unfolded assignment statement.

Configuration

.NET 8.0 (C# 12.0), Visual C 17.9.4
OS: Windows 10
Arch: x64

Regression?

No

[huoyaoyuan]

Can't reproduce with Release configuration. All the statements are producing a simple inc instruction:
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEBDAzgWwB8ABFAAgFkAKWAMzIGUzcBKAWACgBvTsvsumQCWAOwwCyAXgEx6uAHRCA3J178oZANTSAjCo78J0jZrJ7VB9bMYDcUmXP1q+UBUK26lZAPTeyGAAshOwAbURgyAHMYERgobAwYO1wIfAjcDABXAAchABMyfGwwINiySDyIqiTs+TIAcjB8bPqyCGyKmHZLFzd7V0UtMy9fMgB3IJCIwOCyMLLIZqEpu2y42hgwDBCATwtDPu1hnz8Zu2wQkIgwBKSybBk8zJE87DEyADdsDQgRZgxigBrZzMQbSQ7HUYQYEcAC+FmIAGZ/lBMltGJweD0yEjhO9lJx4RwgA=

Program.<<Main>$>g__M|0_0(S ByRef)
    L0000: inc dword ptr [rcx]
    L0002: inc dword ptr [rcx]
    L0004: inc dword ptr [rcx]
    L0006: inc dword ptr [rcx]
    L0008: inc dword ptr [rcx]
    L000a: inc dword ptr [rcx]
    L000c: ret

[uio139021]

My apologies if I'm posting in the wrong place. I am using Visual Studio 2022 17.9.4 debug build and I don't know which C# compiler it is using, to be honest.

[hez2010]

Optimizations won't kick in for any Debug build. You need to test it under Release config.

[huoyaoyuan]

Optimization is only applicable for release configuration.
If you use S s = default instead of passing a new ref s in, JIT will fold the final result of s.i to constant 6 and eliminate all the increments.

[JulieLeeMSFT]

Optimizations won't kick in for any Debug build. You need to test it under Release config.

@uio139021, please try the release config and post back what you see.

[uio139021]

'Release' config:
`
S s = default;
00007FFD2D2E3E70 xor ecx,ecx
00007FFD2D2E3E72 mov dword ptr [rbp-8],ecx

ref int r = ref s.i;
00007FFD2D2E3E75 lea rcx,[rbp-8]
00007FFD2D2E3E79 mov qword ptr [rbp-10h],rcx
r += 1;
00007FFD2D2E3E7D mov rcx,qword ptr [rbp-10h]
00007FFD2D2E3E81 inc dword ptr [rcx]
r = r + 1;
00007FFD2D2E3E83 mov rcx,qword ptr [rbp-10h]
00007FFD2D2E3E87 inc dword ptr [rcx]

ref S rs = ref s;
00007FFD2D2E3E89 lea rcx,[rbp-8]
00007FFD2D2E3E8D mov qword ptr [rbp-18h],rcx
rs.i += 1;
00007FFD2D2E3E91 mov rcx,qword ptr [rbp-18h]
00007FFD2D2E3E95 inc dword ptr [rcx]
rs.i = rs.i + 1;
00007FFD2D2E3E97 mov ecx,dword ptr [rbp-8]
00007FFD2D2E3E9A inc ecx
00007FFD2D2E3E9C mov dword ptr [rbp-8],ecx

s.i += 1; // allocates a redundant ref var on stack
00007FFD2D2E3E9F lea rcx,[rbp-8]
00007FFD2D2E3EA3 mov qword ptr [rbp-20h],rcx
00007FFD2D2E3EA7 mov rcx,qword ptr [rbp-20h]
00007FFD2D2E3EAB inc dword ptr [rcx]
s.i = s.i + 1;
00007FFD2D2E3EAD mov ecx,dword ptr [rbp-8]
00007FFD2D2E3EB0 inc ecx
00007FFD2D2E3EB2 mov dword ptr [rbp-8],ecx
`

[tannergooding]

@uio139021 how are you getting your disassembly?

It looks like you may be getting it from placing a breakpoint under an attached debugger, in which case you may still be getting unoptimized codegen

Such a scenario may also not be accounting for Tiered Compilation as the code will not have been measured as “hot” and been rejitted with optimizations

[hez2010]

@uio139021 It seems that you are inspecting tier-0 code (which is still unoptimized even under Release config). .NET has tiered compilation which only promotes "hot" methods to tier-1 to be optimized. You may try adding <TieredCompilation>false</TieredCompilation> to your csproj and try again.