<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Since all of the functions that use TwoWordPair::Return are part of the Swift runtime and not intended to be overloaded, we could also just make them all `extern "C"`, or give them explicit mangled names, either everywhere or just on x64 Windows.<div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 5, 2017, at 17:30, Thomas Roughton via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class=""><span class="">I've been working on getting Swift running properly on 64-bit Windows and wanted to get some feedback/ideas on a specific issue. </span></div><div class=""><span class=""><br data-mce-bogus="1" class=""></span></div><div class=""><span class="">In swift/Runtime/HeapObject.h, there is a TwoWordPair::Return type intended to return two word-sized values in registers. On Windows, structs are returned indirectly. For some platforms (ARM, i386, 32-bit Windows) this is worked around by packing the results into a 64-bit int.</span></div><div class=""><span class=""><br data-mce-bogus="1" class=""></span></div><div class=""><span class="">We can apply a similar solution on Win64 by packing the results into an __m128 and adopting the __vectorcall calling convention to ensure that the value is passed in a register. However, adopting a new calling convention for methods that interact with TwoWordPair::Return has a fairly major fallout; I've started work in a branch (see the most recent three commits on <a href="https://github.com/troughton/swift/tree/x64-vectorcall" class="">https://github.com/troughton/swift/tree/x64-vectorcall</a>), but it feels <em class="">very</em> messy. The main issue is that __vectorcall using a different mangling scheme, which means we need to special-case in quite a few different places.</span></div><div class=""><span class=""><br data-mce-bogus="1" class=""></span></div><div class=""><span class="">Another alternative would be to adopt the Swift calling convention for swift_allocBox. If this doesn't cause other issues, it seems cleaner and would have a much smaller impact on the code-base. However, there's currently an issue blocking using the Swift calling convention on Windows; it gets sent to MicrosoftMangle in Clang, which doesn't know how to mangle the Swift calling convention (<a href="https://reviews.llvm.org/D31372" class="">https://reviews.llvm.org/D31372</a>). I'd like to resolve this, and it seems like there are two possible implementations:</span></div><div class=""><span class=""><br data-mce-bogus="1" class=""></span></div><div class=""><ul class=""><li class="">Pick an arbitrary prefix to use for SwiftCC and then mangle the rest of the string following the Microsoft convention, knowing that tools won't know how to deal with it.</li><li class="">Alternatively, for functions that use SwiftCC, use the Itanium mangling. This would require a more major refactoring in Clang but might be easier to demangle.</li></ul><div class="">What are people's thoughts on these two issues?</div><div class=""><br data-mce-bogus="1" class=""></div><div class="">- Thomas</div></div></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></div></body></html>