Severe performance issues in code generation by the JIT

[ameisen]

As per this SharpLab example.

For a variety of test cases related to converting between a byte/int and a bool, the JIT (as of Core CLR v4.700.20.6603, which is what SharpLab is using), generates pretty poor code unless I perform a pointer-dereference cast between bool and byte.

What is more interesting and concerning is that I get better results by calling a utility method that does the same thing than doing it in that function. Observe:

public static unsafe int AsInteger(this bool foo) { return *(byte*)&foo; }
public static unsafe int Cast(bool foo) { return *(byte*)&foo; }
public static int CastUtility(bool foo) { return foo.AsInteger(); }

Cast's JIT output:
mov [rsp+0x8], ecx
movzx eax, byte [rsp+0x8]
ret

CastUtility's JIT output:
movzx eax, cl
ret

The codegen is actually substantially worse if I specify that I want to use Roslyn master, as well.

category:cq
theme:optimization
skill-level:intermediate
cost:medium

[SingleAccretion]

It appears that better codegen for CastUtility may not be better after all:

BooleanSums.CalculateSumOfBoolsWithUtilities(Boolean, Boolean, Boolean)
    L0000: movzx eax, cl
    L0003: movzx eax, al
    L0006: movzx edx, dl
    L0009: movzx edx, dl
    L000c: add eax, edx
    L000e: movzx edx, r8b
    L0012: movzx edx, dl
    L0015: add eax, edx
    L0017: ret

BooleanSums.CalculateSumOfBoolsWithCasts(Boolean, Boolean, Boolean)
    L0000: movzx eax, cl
    L0003: movzx edx, dl
    L0006: add eax, edx
    L0008: movzx edx, r8b
    L000c: add eax, edx
    L000e: ret

[ameisen]

So, just getting the value via a utility method produces better code, but using it does not... that's also weird.

I would, regardless, consider this sequence to be a codegen issue as well:

movzx eax, cl
movzx eax, al
movzx edx, dl
movzx edx, dl

It's... very odd. It writes to eax, then immediately writes to it again. It then moves dl to edx... and then immediately does it again.

[ameisen]

Another pathological case

not eax
not eax
...
not eax
not eax

[SingleAccretion]

return ~ ... ~x;

My understanding is that today the JIT doesn't do many of what could be considered "peephole optimizations".

[EgorBo]

oops, closed accidentally

return ~ ... ~x;

This one can be handled as part of #32000

from sharplab link:
// I'm impressed that the JIT compiler is effectively unable to optimize this.

This one is fixed in #32716

Cast vs CastUtility looks interesting, the only difference in jit IR between them is a GT_CAST node in CastUtility

[ameisen]

The NOT(NOT(x)) case also applies to NEG(NEG(x)). Or ~-~-~-~-~-~-~-~-~-x. Or any effectively self-reversible operation.