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

[John McCall via cfe-dev]

> On Mar 4, 2016, at 6:03 AM, Renato Golin <renato.golin at linaro.org> wrote:
> On 3 March 2016 at 21:08, John McCall <rjmccall at apple.com> wrote:
>> Right, this is one very good reason I would prefer to keep the error-result
>> modelled as a parameter rather than mixing it in with the return value.
> 
> Ok, so we're on the same page here.
> 
> 
>> Also, recall that the error-result is supposed to be assigned to a register
>> that isn’t normally used for return values (or arguments, for that matter).
> 
> This looks more complicated, though.
> 
> The back-end knows how to lower standard PCS, so you'll have to teach
> that this particular argument violates that agreement in a very
> predictable fashion, ie. another ABI.

We are using a different swiftcc convention in IR already, and we are fine with
locking the error-result treatment to that CC.

> If the non-PCS register you use is always the same (say the platform
> register), then you'll have to save/restore whenever you cross the
> boundaries between using/not-using (ex. between C and Swift
> functions). This sounds hard to get right.
> 
> One way to know would be to identify all calls in IR that have
> different number of parameters, and do the save/restore there.
> Example:
> 
> define @foo() {
> ...
> call @bar(i32, i8*)
> ...
> }
> 
> define @bar(i32)
> 
> You'd need to change the frame lowering code to identify the
> difference and, instead of bailing out, create the additional spills.

I don’t think we can make this depend on statically recognizing when we’re
passing extra arguments.  That’s why, in our current implementation, whether
or not the register is treated as an ordinary callee-save register or the magic
error result is based on whether there’s an argument to the call (or function
on the callee side) with that specific parameter attribute.

>> A new version of LLVM really can’t just decide to use a different register
>> once there’s an agreed interpretation.
> 
> Good, so there will be a defined ABI.
> 
> It originally sounded like you could choose "any register", but it
> seems you're actually going to define the exact behaviour in all
> supported platforms.

Right.

John.