<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 17, 2014 at 7:55 PM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On May 9, 2014, at 3:46 PM, Reid Kleckner <<a href="mailto:reid@kleckner.net" target="_blank">reid@kleckner.net</a>> wrote:<br>
> Author: rnk<br>
> Date: Fri May  9 17:46:15 2014<br>
> New Revision: 208458<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=208458&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=208458&view=rev</a><br>
> Log:<br>
> MS ABI: Pass 'sret' as the second parameter of instance methods<br>
><br>
> Summary:<br>
> MSVC always passes 'sret' after 'this', unlike GCC.  This required<br>
> changing a number of places in Clang that assumed the sret parameter was<br>
> always first in LLVM IR.<br>
<br>
</span>I apologize for the extremely late review, but this does not seem like the correct solution to me.  Having the sret argument always be the first argument seems like an extremely reasonable IR invariant, and changing it makes it unnecessarily more complicated to implement frontends.  I’m currently attempting to provide a better and more general interface to Clang’s CC lowering, and I would rather not have to tell all clients that they have to handle this one special-case rule.<br>
<br>
A much better fix would be for the x86-64 backend to provide a calling convention — perhaps still called x86_thiscallcc — which passes sret in a different register, and which can ape any other distinctive features of thiscall which we can find.<br>
<br>
Also, as far as I can tell, this behavior is specific to using thiscall, which I believe it’s supported to opt out of on member functions by explicitly using cdecl.</blockquote><div><br></div><div>I agree, this is not a pretty change, but I didn't have any better ideas at the time. It required lots of special code snippets to adjust indices and iterators. =/</div><div><br></div><div>Member functions in MSVC can use any calling convention: cdecl, stdcall, fastcall or vectorcall. Each one of them passes 'this' first and the sret pointer as the second parameter if it is present.</div><div><br></div><div>Initially I did as you propose and created an x86_cdeclmethodcc to deal with this (r200561), but it didn't generalize to stdcall, fastcall, etc, so I gave up and did this instead. It seems clear that this is the correct LLVM IR representation, if not the best internal interface for clang.<br></div><div><br></div><div>Can you elaborate on what abstraction you want to provide? I imagine it would be generally useful to anyone trying to implement a C/C++ FFI for their language. At a high level, all that the call lowering needs to know is whether or not the prototype is for a method with an indirect struct return in the MS ABI. It seemed simplest to represent this as a bit on the ABIArgInfo, but I could see other ways of doing it.</div><div><br></div><div>Have you seen Alexey's ClangToLLVMArgMapping? I think we should be moving in that direction, where we have an explicit map from AST argument to LLVM argument, and we don't rely as much on parallel array iteration.</div></div></div></div>