Add proposal for value types marked as @frozen

[kotlarmilos]

Description

In Swift, when value types are annotated with @frozen, the calling convention directly handles them if they can fit within 4 registers. If the runtime supports passing 4-word structs by value and allows designating the self register, the 4-word struct returns, and an exception register, then binding tools should be able to handle most cases without requiring wrappers.

[jkotas]

I think this is covered in https://github.com/dotnet/designs/blob/3768dc57e7d90f2b21e17464bffcb590b157a810/proposed/swift-interop.md#structsenums paragraph already.

Can we use the plan described in that paragraph? (Handle non-frozen structs in projection layer, and assume that all structs are frozen in the low-level calling convention.)

[jkoritzinsky]

If we want to have both frozen and opaque structs in the signature (and not represent opaque structs as void*), we should take the following approach instead:

• All @frozen layout types are in the signature directly and require no annotations.
• All opaque types are passed as a SwiftOpaque<T> type, where SwiftOpaque<T> is a pointer-sized struct that is treated as a pointer at the ABI level.

This ensures that we don't need to look at type attributes as part of the signature parsing, which we would prefer not to do. This also ensures that we can detect that a return of a Swift function is an opaque struct (and we can ensure we give it the same behavior as Clang gives a swift_indirect_result parameter, which represents a struct return of an opaque struct in Swift.

[jkotas]

we can ensure we give it the same behavior as Clang gives a swift_indirect_result parameter, which represents a struct return of an opaque struct in Swift.

Would SwiftOpaque<T> be the managed method return type or the managed method parameter in the swift_indirect_result case? If it is the earlier, how does the JIT figure out the size of the return buffer to allocate? If it is the latter, how are we going to tell a difference between return value and parameter value?

[jkoritzinsky]

we can ensure we give it the same behavior as Clang gives a swift_indirect_result parameter, which represents a struct return of an opaque struct in Swift.

Would SwiftOpaque<T> be the managed method return type or the managed method parameter in the swift_indirect_result case? If it is the earlier, how does the JIT figure out the size of the return buffer to allocate? If it is the latter, how are we going to tell a difference between return value and parameter value?

You're right, I don't think we would have enough information with just a SwiftOpaque<T> type to get any special experience here, either as the managed return type or as a parameter.

If we were to do it as a return type, the JIT would have to know how to find the value witness table, which we don't want to plumb down that deep. If we were to do it as a parameter, then we wouldn't have a way to know if it was supposed to be a return value or not.

In that case, I'd go back to my original suggestion and Jan's suggestion of "all structs in a signature are @frozen, all opaque types should be passed as void*(and struct returns are a void* parameter at the start of the parameter list)" without a SwiftOpaque<T> type.

[AaronRobinsonMSFT]

"all structs in a signature are @frozen, all opaque types should be passed as void*(and struct returns are a void* parameter at the start of the parameter list)" without a SwiftOpaque type.

It sounds like we are just using void* instead of SwiftOpaque<T>. Why can't we replace the void* in the sentence above with SwiftOpaque<T> and treat it like a pointer sized type? Is the statement here, "SwiftOpaque<T> doesn't give us anymore than void*"?

I simply trying to clarify precisely why void* is any different from a pointer sized value type in this position.

[jkotas]

SwiftOpaque doesn't give us anymore than void*"?

Yep.

[kotlarmilos]

Agreed. Since we can't determine the buffer size without the value witness table, we will handle non-frozen structs in projection layer.