On Mon, 2017-07-24 at 09:32 +0200, Ulrich Weigand wrote: > > Andrew Jeffery <and...@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 >
signature.asc
Description: This is a digitally signed message part
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits