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

[Richard Smith via llvm-dev]

On Tue, Mar 1, 2016 at 5:14 PM, John McCall via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi, all.
>
> Swift uses a non-standard calling convention on its supported platforms.  Implementing this calling convention requires support from LLVM and (to a lesser degree) Clang.  If necessary, we’re willing to keep that support in “private” branches of LLVM and Clang, but we feel it would be better to introduce it in trunk, both to (1) minimize the differences between our branches and trunk and (2) allow other language implementations to take advantage of that support.
>
> We don’t expect this to be particularly controversial, at least in the abstract, since LLVM already includes support for a number of variant, language-specific calling conventions.  Some of Swift's variations are more invasive than those existing conventions, however, so we want to make sure the community is on board before we start landing patches or sending them out for review.
>
> Here’s a brief technical summary of the convention:
>
> In general, the calling convention lowers onto an existing C calling convention; let’s call this the “intermediary convention”.  The intermediary convention is not necessarily the target platform’s standard C convention; for example, we intend to use a VFP convention on iOS ARM targets.  Aggregate arguments and results are translated to sequences of scalar types (possibly just an indirect argument/sret pointer) and, for the most part, passed and returned using the intermediary convention’s rules for a function with that signature.  For example, if struct A expands to the sequence [i32,float,i32], a function type like (A,Int64) -> Bool) would be lowered basically like the C function type bool(*)(int32_t, float, int32_t, int64_t).
>
> There are four general points of deviation from the intermediary convention:
>
>   - We sometimes want to return more values in registers than the convention normally does, and we want to be able to use both integer and floating-point registers.  For example, we want to return a value of struct A, above, purely in registers.  For the most part, I don’t think this is a problem to layer on to an existing IR convention: C frontends will generally use explicit sret arguments when the convention requires them, and so the Swift lowering will produce result types that don’t have legal interpretations as direct results under the C convention.  But we can use a different IR convention if it’s necessary to disambiguate Swift’s desired treatment from the target's normal attempts to retroactively match the C convention.
>
>   - We sometimes have both direct results and indirect results.  It would be nice to take advantage of the sret convention even in the presence of direct results on targets that do use a different (profitable) ABI treatment for it.  I don’t know how well-supported this is in LLVM.
>
>   - We want a special “context” treatment for a certain argument.  A pointer-sized value is passed in an integer register; the same value should be present in that register after the call.  In some cases, the caller may pass a context argument to a function that doesn’t expect one, and this should not trigger undefined behavior.  Both of these rules suggest that the context argument be passed in a register which is normally callee-save.
>
>   - We want a special “error” treatment for a certain argument/result.  A pointer-sized value is passed in an integer register; a different value may be present in that register after the call.  Much like the context treatment, the caller may use the error treatment with a function that doesn’t expect it; this should not trigger undefined behavior, and the existing value should be left in place.  Like the context treatment, this suggests that the error value be passed and returned in a register which is normally callee-save.
>
> Here’s a brief summary of the expected code impact for this.
>
> The Clang impact is relatively minor; it is focused on allowing the Swift runtime to define functions that use the convention.  It adds a new calling convention attribute, a few new parameter attributes constrained to that calling convention, and some relatively un-invasive call lowering code in IR generation.
>
> The LLVM impact is somewhat larger.
>
> Three things in the convention require a possible change to IR:
>
>   - Using sret together with a direct result may or may not “just work".  I certainly don’t see a reason why it shouldn’t work in the middle-end.  Obviously, some targets can’t support it, but we can avoid doing this on those targets.
>
>   - Opting in to the two argument treatments requires new parameter attributes.  We discussed using separate calling conventions; unfortunately, error and context arguments can appear either separately or together, so we’d really need several new conventions for all the valid combinations.  Furthermore, calling a context-free function with an ignored context argument could turn into a call to a function using a mismatched calling convention, which LLVM IR generally treats as undefined behavior.  Also, it wasn’t obvious that just a calling convention would be sufficient for the error treatment; see the next bullet.
>
>   - The “error” treatment requires some way to (1) pass and receive the value in the caller and (2) receive and change the value in the callee.  The best way we could think of to represent this was to pretend that the argument is actually passed indirectly; the value is “passed” by storing to the pointer and “received” by loading from it.  To simplify backend lowering, we require the argument to be a special kind of swifterror alloca that can only be loaded, stored, and passed as a swifterror argument; in the callee, swifterror arguments have similar restrictions.  This ends up being fairly invasive in the backend, unfortunately.
>
> The convention also requires a few changes to the targets that support the convention, to deal with the context and error treatments and to return more values in registers.
>
> Anyway, I would appreciate your thoughts.

I consider it completely reasonable for Clang to support this calling
convention and the associated attributes, especially given the minor
impact you describe above.