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

On 2 March 2016 at 19:01, John McCall <rjmccall at apple.com>
wrote:
> Also, just a quick question.  I’m happy to continue to talk about the
actual
> design and implementation of LLVM IR on this point, and I’d be happy to
> put out the actual patch we’re initially proposing.  Obviously, all of this
code
> needs to go through the normal LLVM/Clang code review processes.  But
> before we continue with that, I just want to clarify one important point:
assuming
> that the actual implementation ends up satisfying your technical
requirements,
> do you have any objections to the general idea of supporting the Swift CC
> in mainline LLVM?
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.

cheers,
--renato

> On Mar 2, 2016, at 11:04 AM, Renato Golin <renato.golin at
linaro.org> wrote:
> On 2 March 2016 at 19:01, John McCall <rjmccall at apple.com> wrote:
>> Also, just a quick question.  I’m happy to continue to talk about the
actual
>> design and implementation of LLVM IR on this point, and I’d be happy to
>> put out the actual patch we’re initially proposing.  Obviously, all of
this code
>> needs to go through the normal LLVM/Clang code review processes.  But
>> before we continue with that, I just want to clarify one important
point: assuming
>> that the actual implementation ends up satisfying your technical
requirements,
>> do you have any objections to the general idea of supporting the Swift
CC
>> in mainline LLVM?
> 
> 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.
Okay, thank you.  Back to technical discussion. :)

John.

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?

David

On 2 March 2016 at 19:09, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> 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?
That's a very good point. We don't have that many chances of
refactoring largely forgotten and undocumented code.

--renato

> 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.