<html><body><div><span>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><span><br data-mce-bogus="1"></span></div><div><span>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><span><br data-mce-bogus="1"></span></div><div><span>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">https://github.com/troughton/swift/tree/x64-vectorcall</a>), but it feels <em>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><span><br data-mce-bogus="1"></span></div><div><span>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">https://reviews.llvm.org/D31372</a>). I'd like to resolve this, and it seems like there are two possible implementations:</span></div><div><span><br data-mce-bogus="1"></span></div><div><ul><li>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>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>What are people's thoughts on these two issues?</div><div><br data-mce-bogus="1"></div><div>- Thomas</div></div></body></html>