r208458 - MS ABI: Pass 'sret' as the second parameter of instance methods

[Reid Kleckner]

On Fri, Oct 17, 2014 at 7:55 PM, John McCall <rjmccall at apple.com> wrote:

> On May 9, 2014, at 3:46 PM, Reid Kleckner <reid at kleckner.net> wrote:
> > Author: rnk
> > Date: Fri May  9 17:46:15 2014
> > New Revision: 208458
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=208458&view=rev
> > Log:
> > MS ABI: Pass 'sret' as the second parameter of instance methods
> >
> > Summary:
> > MSVC always passes 'sret' after 'this', unlike GCC.  This required
> > changing a number of places in Clang that assumed the sret parameter was
> > always first in LLVM IR.
>
> 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.
>
> 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.
>
> 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.


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. =/

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.

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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141021/312e7dbf/attachment.html>