inplace increment operator causes register spilling (.NET 7)

[lakecherry]

ushort frequency;
...
if (++this.frequency > byte.MaxValue)

expected x64:

00007FFB1BBE8188  inc         word ptr [rax]  
00007FFB1BBE818B  cmp         word ptr [rax],0FFh  

reality x64:

00007FFB1BC08248  movzx       ecx,word ptr [rax]  
00007FFB1BC0824B  inc         ecx  
00007FFB1BC0824D  movzx       ecx,cx  
00007FFB1BC08250  mov         word ptr [rax],cx  
00007FFB1BC08253  cmp         ecx,0FFh  

separating increment and compare gets expected code:

this.frequency++;
if (this.frequency > byte.MaxValue)

same for int ... any recommendations? (the oneliner version would of course be much more coding-friendly)

[Clockwork-Muse]

the oneliner version would of course be much more coding-friendly

Increment inside a condition is slightly dangerous, in that it can cause confusion for less experienced coders (especially if they try to "fix" it to be a postfix increment, here).

[lakecherry]

Yes, balancing code readability and laziness is a very personal thing ;) ... nonetheless i am surprised that such basic operations don't get optimized ...

[tannergooding]

The post-increment and pre-increment operators are likewise not exactly "basic", even if they appear to be.

In IL, someInt32++ is represented as:

ldarg.1
ldc.i4.1
add
starg.s x

Where-as someByte++ is represented as:

ldarg.1
ldc.i4.1
add
conv.u1
starg.s x

This is because there doesn't exist a stack type for byte, the ldarg.1 implicitly upcasts it to an i4.

The reason there isn't a stack type for byte or short is largely because such operations are generally not as optimizable or efficient at the hardware level. CPUs largely operate on 32-bit or 64-bit registers. They sometimes provide access to 8 or 16-bit subsections of those registers, but accessing them often involves (internally) a set of additional bit masking to be done to ensure the upper bits are preserved, which can in turn hinder register renaming or other tricks modern CPUs do and thus introduce dependency chains or partial stalls. This naturally makes accessing such subsections of the register more expensive. -- Accessing 32-bits of a 64-bit register is often not as expensive, because there is an implicit zeroing semantic, of the upper bits, that exists.

There are also other considerations at play, such as operations where you both read and write the memory location in a single instruction being more expensive, inc word ptr [rax]; cmp word ptr [rax], 0FFh for example has 3 memory accesses, a full dependency chain, and some implicit masking. Broken down:

• inc is [5, 11] cycles; [3, 4] uops; 4 ports`
• cmp is [5, 6] cycles; [1, 2] uops; 2 ports

On the other hand, the code we generate is a little bit longer. Broken down:

• movzx is [1, 5] cycles; 1 uop; 1 port
• inc is 1 cycle; 1 uop; 1 port
• movzx is 1 cycle; 1 uop; 1 port;
• mov is [3, 11] cycles; [1, 2] uops; 2 ports
• cmp is 1 cycle; 1 uop; 1 port

Taking at face value, you have [10, 17] cycles; [4, 6] uops; 6 ports vs [7, 19] cycles; [5, 6] uops; 6 ports. But, there's a nuance here in that some of these instructions can be free in some cases (movzx r32, r8 for example is free, while movzx r32, r16 is not) or can be pipelined when a memory operation isn't being done. Some can also be merged into other operations (write-combining), etc.

So we end up with something that looks more expensive, but can actually end up being cheaper and in practice averages to the same cost, but which makes it easier to produce better optimized code in more complex patterns, particularly if a value is reused.

If you take a simplistic example, and look at what Clang or MSVC generate, you'll note it is likewise similar to what we generate here in .NET: godbolt

Playing around with how the value gets reused or not can show other interesting examples as well and how this can subtly influence codegen.

[lakecherry]

Wow, thank you for this comprehensive explanation! Those details are exactly what helps me understanding ...
The reason for using "ushort" instead of "int" in my case is saving memory (some of those struct arrays can grow up to millions of elements).