<html><body><p><tt><font size="2">Andrew Jeffery <andrew@aj.id.au> wrote on 24.07.2017 03:54:05:<br><br>> > > > + bool shouldPassIndirectlyForSwift(CharUnits totalSize,<br>> > > > + ArrayRef<llvm::Type*> scalars,<br>> > > > + bool asReturnValue) constoverride {<br>> > > > + return occupiesMoreThan(CGT, scalars, /*total*/ 4);<br>> > <br>> > I don't know much about Swift; the code changes seem reasonable. One <br>> > question I have is: from where does this number 4 come? Is there some <br>> > corresponding patch to Swift that this matches?<br>> <br>> As far as I'm aware a patch to Swift is not necessary, rather 4 comes<br>> from Ulrich's '[PowerPC] Support multiple return values with fast isel'<br>> patch[1] which allows up to 4 values to be returned in registers.<br>> <br>> To give some confidence, with this patch Swift builds and the tests<br>> pass for PPC64 on PPC64. Looking at the other implementations of<br>> shouldPassIndirectlyForSwift() none of them seem to have behaviour<br>> dependent on asReturnValue, however must say I'm not certain about the<br>> false (argument) case. Maybe Ulrich can provide some insight?<br></font></tt><br><tt><font size="2">That LLVM back-end patch simply *allows* front-ends to return integers</font></tt><br><tt><font size="2">in up to 4 registers. (I did this because Anton Blanchard pointed out</font></tt><br><tt><font size="2">in PR 26190 that Swift at that time wanted to return three values in</font></tt><br><tt><font size="2">registers.) The choice of 4 here is somewhat arbitrary, and the back-</font></tt><br><tt><font size="2">end could as well be changed to allow using up to 8 registers; in fact,</font></tt><br><tt><font size="2">this would even be more logical since it would allow using any of the</font></tt><br><tt><font size="2">argument registers also as return register.</font></tt><br><br><tt><font size="2">But this has really nothing to do with how Swift choses to *use* this.</font></tt><br><tt><font size="2">Which and how many values Swift wants to return in registers is in</font></tt><br><tt><font size="2">the end a choice to be made by the front-end. Ideally, there should</font></tt><br><tt><font size="2">be an ABI document specifying the Swift ABI for each platform. I</font></tt><br><tt><font size="2">don't really know what Swift is trying to do here; in particular, I</font></tt><br><tt><font size="2">do not know whether Swift is attempting to be compatible with some</font></tt><br><tt><font size="2">other ABI to allow interoperability, or whether this is a completely</font></tt><br><tt><font size="2">private choice. So I cannot really say whether 4 is "correct" here.</font></tt><br><br><tt><font size="2">Bye,</font></tt><br><tt><font size="2">Ulrich</font></tt><br><BR>
</body></html>