> On Mar 22, 2016, at 12:25 PM, Joe Groff <jgr...@apple.com> wrote:
>> On Mar 22, 2016, at 12:06 PM, Bryan Chan <bryan.c...@ca.ibm.com
>> <mailto:bryan.c...@ca.ibm.com>> wrote:
>>
>> jgr...@apple.com <mailto:jgr...@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.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
