[mono][swift-interop] Support for Swift struct lowering in direct P/Invoke returns

[matouskozak]

Description

This PR adds support in Mono runtime for Swift @frozen struct lowering in returns. The scope is limited to direct P/Invoke scenario with reverse P/Invoke following up in a separate PR. The changes cover support over all Mono supported backend engines: miniJIT, interpreter and AOT.

In Swift, structures can be lowered into <= 4 primitives that are subsequently returned via registers. This is a simplified scenario in comparison to lowering of arguments where lowered elements can also be passed on stack when maximum number of registers used for arguments is exceeded.

Implementation

The lowering support for returns is handled at the codegen level (mini-<arch>.c) by introducing new storage type (ArgSwiftVtypeLoweredRet/ArgSwiftValuetypeLoweredRet) that represents a structure that is returned via combination of integer and float registers.

The first step of struct lowering is handled in get_call_info -> add_return_valuetype_swiftcall where struct lowering is computed. In scenarios where struct can be lowered (fits in <= 4 registers) the newly introduced storage type is used, otherwise the struct is returned via reference.

1. Returned by lowered sequence:

   • The re-composition of struct is handled in emit_move_return_value where the values stored in return registers are loaded into prepared memory at specific offsets.

2. Returned by reference:

   • On arm64, handled as regular ArgVtypeByRef with no extra changes.
   • On x64, handled as ArgValuetypeAddrInIReg with specific handling where the reference is temporarily hold in R10 reg. and moved to RAX reg. (amd64_handle_swift_return_buffer_reg) before emitting the call to native code. That's because Swift expects that the return buffer reference is passed in RAX reg. but in Mono runtime, this reg. serves multiple purposes and we cannot easily prevent RAX clobbering by other parts of code.

Verification

The changes are verified using the Interop/Swift/SwiftRetAbiStress runtime tests. The extended set of 5000 test cases was used locally to further verify the lowering support. The fullAOT functionality was only verified in local settings due to missing coverage on CI.

Other changes

• refactoring of argument Swift @frozen struct lowering in method-to-ir.c
• refactoring of Swift return buffer handling (amd64_handle_swift_return_buffer_reg)
• adding more #ifdef MONO_ARCH_HAVE_SWIFTCALL to better separate swiftcall support
• add missing ArgSwiftError entry in mono_arch_get_llvm_call_info on arm64. This is just a placeholder because we don't compile P/Invoke wrappers by LLVM. However, on arm64, the missing entry was causing failures in AOT-llvm compilation.

---

Contributes to #102077

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @lambdageek
See info in area-owners.md if you want to be subscribed.

[jkurdek]

Good job!

You mentioned you tested these changes on extended set of 5000 tests in Interop/Swift/SwiftRetAbiStress. Is there any description somewhere how to get / generate this set? Could be useful for testing other changes.

[jkurdek]

It is not clear to me why we can use mono_class_get_byref_type (mono_defaults.typed_reference_class) instead of mono_class_get_byref_type (klass);

[matouskozak]

It is not clear to me why we can use mono_class_get_byref_type (mono_defaults.typed_reference_class) instead of mono_class_get_byref_type (klass);

I'm not sure either. I did some investigating and it seems that the all byref types get changed to generic MONO_TYPE_I which is then handled by codegen as a pointer-sized integer. I will change it to mono_class_get_byref_type (klass) as it makes more sense.

[jkurdek]

Why is this change necessary only for amd64?

[matouskozak]

On arm64, the argument and return registers are the same (x0-x7). Whereas on amd64, different registers are used for arguments and returns.

For arm64, this gets handled at

runtime/src/mono/mono/mini/tramp-arm64.c

Lines 773 to 779 in 4185f94

	/* set all general purpose registers to CallContext */
	for (i = 0; i < PARAM_REGS; i++)
	arm_strx (code, i, ARMREG_IP0, MONO_STRUCT_OFFSET (CallContext, gregs) + i * sizeof (host_mgreg_t));
	/* set all floating registers to CallContext */
	for (i = 0; i < FP_PARAM_REGS; i++)
	arm_strfpx (code, i, ARMREG_IP0, MONO_STRUCT_OFFSET (CallContext, fregs) + i * sizeof (double));

[fanyang-mono]

Is there any follow-up work we need to do for LLVM?

[fanyang-mono]

Is there a better place, where we could set this value for Mono instead of repeating it for each architecture? Like somewhere in cmake logic?

[matouskozak]

I think that it could be set in src/mono/CMakeLists.txt by something like:

if ((TARGET_AMD64 OR TARGET_ARM64) AND (TARGET_OSX or TARGET_APPLE_MOBILE))
    set(MONO_ARCH_HAVE_SWIFTCALL 1)
endif()

However, CoreCLR also does set it in the respective arch files e.g.

runtime/src/coreclr/jit/targetamd64.h

Line 563 in a5c1c9f

#define SWIFT_SUPPORT

What do you think is better? (cc: @kotlarmilos, @jkurdek)

[kotlarmilos]

It might be cleaner to move it to src/mono/CMakeLists.txt, but don't have a strong opinion about it. Since this is not a new change, I suggest doing it in a follow-up PR.

[matouskozak]

Is there any follow-up work we need to do for LLVM?

At the moment no, Mono doesn't use LLVM to compile P/Invoke wrappers so it fallbacks to Mini. I just added the entries inside mono_arch_get_llvm_call_info for arm64 to avoid asserting there (not needed on amd64)