JIT: Wrapper around a float generates additional asm compared to float

[MechWarrior99]

Description

A wrapper around a float generates additional asm when used compared to using a float. While a wrapper around a int will generate the same asm to a int.

static FloatWrapper WrapperAdd(FloatWrapper fw1, FloatWrapper fw2)
{
    return fw1 + fw2;
}

static float FloatAdd(float f1, float f2)
{
     return f1 + f2;   
}

readonly struct FloatWrapper(float value)
{
    private readonly float _value = value;

    public static implicit operator float (FloatWrapperx) => x._value;
    public static implicit operator FloatWrapper(float x) => new(x);

    public static FloatWrapper operator+(FloatWrapperx, FloatWrappery) => x._value + y._value;
}

Generated asm:

Program.<<Main>$>g__WrapperAdd|0_0(FloatWrapper, FloatWrapper)
    L0000: vmovd xmm0, ecx
    L0004: vmovd xmm1, edx
    L0008: vaddss xmm0, xmm0, xmm1
    L000c: vmovd eax, xmm0
    L0010: ret

Program.<<Main>$>g__FloatAdd|0_1(Single, Single)
    L0000: vaddss xmm0, xmm0, xmm1
    L0004: ret

Generated asm when using the same code but change all floats to ints.

Program.<<Main>$>g__WrapperAdd|0_0(IntWrapper, IntWrapper)
    L0000: lea eax, [rcx+rdx]
    L0003: ret

Program.<<Main>$>g__IntAdd|0_1(Int32, Int32)
    L0000: lea eax, [rcx+rdx]
    L0003: ret

Configuration

net 9
Windows
x64

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

This is expected ABI difference. As you can see in the asm, floats are passed in xmm registers, while wrapper structs are passed in integer registers. This matches the platform C ABI:

https://godbolt.org/z/bYvTjcoxn

struct FloatWrapper
{
    float value;
};

float M1(float a, float b)
{
    return a + b;
}

FloatWrapper M2(FloatWrapper a, FloatWrapper b)
{
    return { a.value + b.value };
}

float M1(float,float) PROC                                 ; M1
; File C:\Windows\TEMP\compiler-explorer-compilerv0j1Xp\example.cpp
; Line 9
        addss   xmm0, xmm1
; Line 10
        ret     0
float M1(float,float) ENDP                                 ; M1
_TEXT   ENDS

; Function compile flags: /Ogtpy
_TEXT   SEGMENT
FloatWrapper M2(FloatWrapper,FloatWrapper) PROC           ; M2
; File C:\Windows\TEMP\compiler-explorer-compilerv0j1Xp\example.cpp
; Line 13
        movd    xmm1, edx
        movd    xmm0, ecx
; Line 14
        addss   xmm1, xmm0
        movd    eax, xmm1
; Line 15
        ret     0
FloatWrapper M2(FloatWrapper,FloatWrapper) ENDP           ; M2

[tannergooding]

This is expected and is determined by the ABI (Application Binary Interface) for the underlying platform.

In general T and struct S { T value; } are not equivalent. They are considered to have different layouts, potentially different packing, potentially different passing or returning conventions, etc. There are some cases that may line up and others that will not.

Likewise, struct S { uint x; ushort y; } and struct S { uint x; ushort y; ushort padding; } are not equivalent. Explicitly declaring fields for padding makes them "exist" and it changes the semantics of how copying, passing, and other considerations happen.

You also have cases where the behavior can differ based on platform (Windows, Linux, MacOS, etc), architecture (x86, x64, Arm32, Arm64, etc), calling convention (cdecl, stdcall, fastcall, vectorcall, system_v, winx64, arm64, etc), whether its a static vs instance method, whether its integer vs float vs mixed field types, whether its a power of 2, and much more (including various combinations of these but not others).

You can even have cases where int vs uint are not equivalent and where these are passed differently, so it can create interop incompatibilities if you use the wrong type compared to native.

---

Ultimately, you need to be careful and considerate when defining wrapper types vs using primitives. What is "best" is scenario dependent and often varies based on how the type or data is likely to be used and extended.

You should also consider that many small methods are likely to be inlined in which case differences may disappear altogether because you no longer have to respect the calling convention and can optimize the codegen accordingly. Hence simply looking at isolated disasm isn't necessarily sufficient; you need to look at and measure types in real world scenarios/code.

[jilles-sg]

Technically, it would be possible to have a layout kind like Rust's #[repr(transparent)] (documented at https://doc.rust-lang.org/stable/reference/type-layout.html#the-transparent-representation ) which gives structs with a single field the same layout and ABI as their field (with some extra details for zero-sized types). Also, similar to how LayoutKind.Auto violates the C ABI by reordering fields, it could violate the C ABI by passing single floating point numbers directly.

However, I'm not sure whether this is worth the effort.

[tannergooding]

That's been proposed previously and rejected (was discussed extensively around #13788 and related issues).

It really only benefits methods which cannot be inlined and interop scenarios. For methods that cannot be inlined, its likely large enough that the cost of the wrapper not being 1-to-1 for such types won't matter. For interop scenarios, LibraryImport and other generators trivialize the wrapping/unwrapping to make it correct. Such helper methods are then small and inlineable.

-- CC. @AaronRobinsonMSFT, @jkoritzinsky