<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 5, 2017, at 8:30 PM, 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></div></div></blockquote><div><br class=""></div>I think it wouldn't be the worst thing to just ignore SwiftCC when mangling for the MSVC ABI for now, at least when mangling a top-level function type.</div><div><br class=""></div><div>John.</div></body></html>