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

[Andrew Jeffery via cfe-commits]

On Mon, 2017-07-24 at 09:32 +0200, Ulrich Weigand wrote:
> > 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.

Thanks the response! I naively approached the patch from a "how to make
it work" perspective rather than a "how *should* it work", and you've
exposed that here. Swift document the ABI commitments[1] and calling
convention[2], which I'd looked over in the early days of developing
the patch but haven't recently revisited them. I need to take a deeper
dive to better understand the aims and how these should be exploited on
Power so I can answer the question.

Cheers,

Andrew

[1] https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
[2] https://github.com/apple/swift/blob/master/docs/CallingConvention.rst

> 
> Bye,
> Ulrich
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170725/935a4c61/attachment.sig>