[llvm-dev] [cfe-dev] RFC: Implementing the Swift calling convention in LLVM and Clang

[John McCall via llvm-dev]

> On Mar 2, 2016, at 11:09 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> On 2 Mar 2016, at 19:04, Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> 
>> I personally don't. I think we should treat Swift as any other
>> language that we support, and if we can't use existing mechanisms in
>> the back-end to lower Swift, then we need to expand the back-end to
>> support that.
>> 
>> That being said, if the Swift support starts to bit-rot (if, for
>> instance, Apple stops supporting it in the future), it will be harder
>> to clean up the back-end from its CC. But that, IMHO, is a very
>> far-fetched future and a small price to pay.
> 
> The Swift calling model also seems to be quite generally useful.  I can imagine that VMKit would have used it, if it had been available then.
> 
> My only concern is that the implicit contract between the front and back ends, with regard to calling convention, is already complex, already largely undocumented, and already difficult to infer even if you have the relevant platform ABI document in front of you.  It is badly in need of some cleanup and I wonder if the desire to minimise diffs for Swift might provide Apple with some incentive to spend a little bit of engineering effort on it?

I have to say that, while I completely agree with you, I also deliberately made an effort in the design of our lowering to avoid as many of those existing complexities as I could. :)  So I’m not sure we’d be an ideal vehicle for cleaning up the C lowering model.  I’m also wary about turning this project — already somewhat complex — into a massive undertaking, which I’m afraid that changing general CC lowering rules would be.  Furthermore, I’m concerned that anything we did here would just turn into an *extra* dimension of complexity for the backend, rather than replacing the current complexity, because it’s not obvious that targets would be able to simply drop their existing ad-hoc interpretation rules.  But if you have concrete ideas about this, maybe we can find a way to work them in.

The basic tension in CC lowering is between wanting simple cases to just work without further annotations and the need to cover the full gamut of special-case ABI rules.  If we didn’t care about the former, we could just require every call and the function to completely describe the ABI to use — "argument 1 is in R0, argument 2 is in R12, argument 3 is at offset 48 on the stack, and we need 64 bytes on the stack and it has to be 16-byte-aligned at the call”.  But dealing with that level of generality at every single call boundary would be a huge pain for backends, and we’d still need special code for things like varargs.  So instead we’ve evolved all these informal protocols between frontends and backends.  The informal protocols are… annoying, but I think the bigger problem is that they’re undocumented, and it’s unclear to everybody involved what’s supposed to happen when you go outside them.  So the first step, I think, would just be to document as many of those informal, target-specific protocols as we can, and then from there maybe we can find commonalities that can be usefully generalized.

John.