[swift-dev] Returning more than two scalars from C code

John McCall rjmccall at apple.com
Tue Mar 22 14:51:52 CDT 2016

> On Mar 22, 2016, at 12:25 PM, Joe Groff <jgroff at apple.com> wrote:
>> On Mar 22, 2016, at 12:06 PM, Bryan Chan <bryan.chan at ca.ibm.com <mailto:bryan.chan at ca.ibm.com>> wrote:
>> jgroff at apple.com <mailto:jgroff at apple.com> wrote on 2016-03-22 02:37:47 PM:
>> > The runtime functions are hacked in various unsavory ways to give 
>> > them Swift-like calling conventions. Many of them also have 
>> > important semantics that the compiler needs to be aware of, so if 
>> > they aren't exported as standard library API in some way, you really
>> > shouldn't interact with them directly. 
>> > (swift_class_getInstanceExtents happens to be OK, but what are you 
>> > trying to do with it?)
>> I am trying to build Swift on a different architecture (s390x). This
>> function was causing crashes due to the ABI mismatch, and I also
>> found that the issue is not 100% fixed on x86 either, so I wondered
>> if the community has an opinion on the right way to deal with this
>> in the runtime, or if the answer is simply "don't do this for
>> 3-scalar returns".
> Yeah, there's no good way right now to return three scalars from Clang. swift_class_getInstanceExtents and a few other runtime entrypoints like allocBox and allocError use the `TwoWordPair::Return` hack to use types that happen to return in two registers on i386, x86_64, armv7, and arm64. If s390x's C ABI doesn't define any such types, you might need to wait for proper support for Swift calling conventions in Clang. I believe it's on John McCall's near-term todo list to do that.

To be clear, you'll still need to implement the swiftcc convention for your target in LLVM/clang, so it will still take some compiler implementation expertise to get right.  But at least the compatibility assumptions will be explicit.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160322/b0d3e85f/attachment.html>

More information about the swift-dev mailing list