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

[Renato Golin via cfe-dev]

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.

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.


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


> It seems to me that an abi(“context”) attribute
> would be more like the latter than the former: any target that supports swiftcc
> would also have to assign a stable meaning for abi(“context”).

Makes sense.

cheers,
--renato