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

[John McCall via llvm-dev]

> On Mar 2, 2016, at 3:41 AM, Bruce Hoult <bruce at hoult.org> wrote:
> 
> I've done the "environment passed in a callee-save register" thing before, just by using the C compiler's ability to reserve a register and map a particular C global variable to it.
> 
> As you say, there is then no problem when you call code (let's call it "library code") which doesn't expect it. The library code just automatically saves and restores that register if it needs it.
> 
> However -- and probably you've thought of this -- there is a problem with callbacks from library code that doesn't know about the environment argument. The library might save the environment register, put something else there, and then call back to your code that expects the environment to be set up. Boom!

Yes, that’s a well-known problem with trying to reserve a register for a ubiquitous environment.  That’s not what we’re doing here, though.  The error result is more like a special argument / result to the function, in as much it's only actually required that the value be in that register at the call boundary.

Swift uses a non-zero-cost exceptions scheme for its primary error handling; this result is used to indicate whether (and what) a function throws.  The basic idea is that the callee sets the register to either null, meaning it didn’t throw, or an error value, meaning it did; except actually it’s better for code size if the caller sets the register to null on entry.

The considerations on the choice of register are as follows:

1. We want to be able to freely convert an opaque function value that’s known not to throw to a function that can.  The idea here is that the caller initializes the register to null.  If the callee is dynamically potentially-throwing, it expects the register to be null on entry and may or may not set it to be some other value.  If the callee is not dynamically potentially-throwing, it leaves the register alone because it considers it to be callee-save.  So there’s a hard requirement that whatever register we choose be considered callee-save by the Swift convention.

2. Swift code frequently calls C code.  It’s good for performance and code size if a function doesn’t have to save and restore the error-result register just because it’s calling a C function.  So we really want it to be callee-save in the C convention, too.  This also means that we don’t have to worry about the dynamic linker messing us up.

3. We don’t want to penalize other Swift functions by claiming an argument/result register that they would otherwise use.  Of course, they wouldn’t normally use a callee-save register.

John.

> This callback might be a function that you passed explicitly as an argument, a function pointed to by a global hook, or a virtual function of an object you passed (derived from a base class that the library knows about).
> 
> Any such callbacks need to either 1) not use the environment register, or 2) set up the environment register from somewhere else before using it or calling other code that uses it, or 3) be a wrapper/thunk that sets up the environment register before calling the real function.
> 
> 
> On Wed, Mar 2, 2016 at 4:14 AM, John McCall via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-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.
> 
> John.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160302/4371fbf6/attachment-0001.html>