<html><body><p><tt>Thanks for your responses so far. It took me a while to fully appreciate</tt><br><tt>what all this means.</tt><br><br><tt>I have read through John's mail thread on llvm-dev about adding the swiftcc</tt><br><tt>convention to LLVM/Clang. I don't think that discussion mentioned adding</tt><br><tt>Clang support for C++ functions returning aggregates in multiple registers</tt><br><tt>for targets that currently use sret, because, in John's words, &quot;we don't</tt><br><tt>use the Swift CC to call C functions.&quot; But aren't these runtime functions</tt><br><tt>using TwoWordPair::Return doing exactly that?</tt><br><br><tt>On i386 and ARM, the TwoWordPair::Return type is masqueraded as a 64-bit</tt><br><tt>unsigned long long so that the returned values are passed in a register</tt><br><tt>pair. This trick is not portable, and infeasible on at least s390x.</tt><br><br><tt>A portable solution would be to implement such runtime functions in Swift,</tt><br><tt>and make them retrieve the needed results from two calls to C++, instead</tt><br><tt>of one call to a C++ function that returns a pair. The Swift function</tt><br><tt>can then return value pairs as usual. This seems much cleaner and simpler.</tt><br><br><tt>Bryan</tt><br><br><br><tt>rjmccall@apple.com wrote on 2016-03-22 03:51:52 PM:<br><br>&gt; On Mar 22, 2016, at 12:25 PM, Joe Groff &lt;jgroff@apple.com&gt; wrote:</tt><br><tt>&gt; &gt; On Mar 22, 2016, at 12:06 PM, Bryan Chan &lt;bryan.chan@ca.ibm.com&gt; wrote:</tt><br><tt>&gt; &gt; <br>&gt; &gt; &gt; jgroff@apple.com wrote on 2016-03-22 02:37:47 PM:<br>&gt; &gt; &gt; <br>&gt; &gt; &gt; &gt; The runtime functions are hacked in various unsavory ways to give <br>&gt; &gt; &gt; &gt; them Swift-like calling conventions. Many of them also have <br>&gt; &gt; &gt; &gt; important semantics that the compiler needs to be aware of, so if <br>&gt; &gt; &gt; &gt; they aren't exported as standard library API in some way, you really<br>&gt; &gt; &gt; &gt; shouldn't interact with them directly. <br>&gt; &gt; &gt; &gt; (swift_class_getInstanceExtents happens to be OK, but what are you <br>&gt; &gt; &gt; &gt; trying to do with it?)<br>&gt; &gt; &gt; <br>&gt; &gt; &gt; I am trying to build Swift on a different architecture (s390x). This<br>&gt; &gt; &gt; function was causing crashes due to the ABI mismatch, and I also<br>&gt; &gt; &gt; found that the issue is not 100% fixed on x86 either, so I wondered<br>&gt; &gt; &gt; if the community has an opinion on the right way to deal with this<br>&gt; &gt; &gt; in the runtime, or if the answer is simply &quot;don't do this for<br>&gt; &gt; &gt; 3-scalar returns&quot;.</tt><br><tt>&gt; &gt;</tt><br><tt>&gt; &gt; Yeah, there's no good way right now to return three scalars from <br>&gt; &gt; Clang. swift_class_getInstanceExtents and a few other runtime <br>&gt; &gt; entrypoints like allocBox and allocError use the <br>&gt; &gt; `TwoWordPair::Return` hack to use types that happen to return in two<br>&gt; &gt; registers on i386, x86_64, armv7, and arm64. If s390x's C ABI <br>&gt; &gt; doesn't define any such types, you might need to wait for proper <br>&gt; &gt; support for Swift calling conventions in Clang. I believe it's on <br>&gt; &gt; John McCall's near-term todo list to do that.</tt><br><tt>&gt; <br>&gt; To be clear, you'll still need to implement the swiftcc convention <br>&gt; for your target in LLVM/clang, so it will still take some compiler <br>&gt; implementation expertise to get right. &nbsp;But at least the <br>&gt; compatibility assumptions will be explicit.</tt><BR>
</body></html>