[PATCH v3] [PPC64]: Add support for Swift calling convention

[Ulrich Weigand via cfe-commits]

Andrew Jeffery <andrew at aj.id.au> wrote on 24.07.2017 03:54:05:

> > > > +  bool shouldPassIndirectlyForSwift(CharUnits totalSize,
> > > > +                                    ArrayRef<llvm::Type*> scalars,
> > > > +                                    bool asReturnValue)
constoverride {
> > > > +    return occupiesMoreThan(CGT, scalars, /*total*/ 4);
> >
> > I don't know much about Swift; the code changes seem reasonable. One
> > question I have is: from where does this number 4 come? Is there some
> > corresponding patch to Swift that this matches?
>
> As far as I'm aware a patch to Swift is not necessary, rather 4 comes
> from Ulrich's '[PowerPC] Support multiple return values with fast isel'
> patch[1] which allows up to 4 values to be returned in registers.
>
> To give some confidence, with this patch Swift builds and the tests
> pass for PPC64 on PPC64. Looking at the other implementations of
> shouldPassIndirectlyForSwift() none of them seem to have behaviour
> dependent on asReturnValue, however must say I'm not certain about the
> false (argument) case. Maybe Ulrich can provide some insight?

That LLVM back-end patch simply *allows* front-ends to return integers
in up to 4 registers.  (I did this because Anton Blanchard pointed out
in PR 26190 that Swift at that time wanted to return three values in
registers.)  The choice of 4 here is somewhat arbitrary, and the back-
end could as well be changed to allow using up to 8 registers; in fact,
this would even be more logical since it would allow using any of the
argument registers also as return register.

But this has really nothing to do with how Swift choses to *use* this.
Which and how many values Swift wants to return in registers is in
the end a choice to be made by the front-end.  Ideally, there should
be an ABI document specifying the Swift ABI for each platform.  I
don't really know what Swift is trying to do here; in particular, I
do not know whether Swift is attempting to be compatible with some
other ABI to allow interoperability, or whether this is a completely
private choice.  So I cannot really say whether 4 is "correct" here.

Bye,
Ulrich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170724/8799e055/attachment-0001.html>