[PATCH] reserve constants for Swift bitcode compatibility

[Eric Christopher]

On Sat, Jul 25, 2015 at 10:37 PM Bob Wilson <bob.wilson at apple.com> wrote:

> On Jul 17, 2015, at 5:26 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>
>
> On Jul 15, 2015, at 10:30 PM, Eric Christopher <echristo at gmail.com> wrote:
>
> Hi Bob,
>
> I think the calling convention patch is fairly obviously ok. The bar is
> usually a little higher for things like attributes and flags, any hope for
> a bit more explanation there?
>
>
> Sure. While I’m at it, I should correct my previous remark about bitcode
> compatibility with Xcode 7. The Swift calling convention at issue here is
> still under development. I don’t know when it will be released. That said,
> people are working on it and it will help us to reserve these values and
> avoid bitcode conflicts.
>
> Swift has two special cases for argument passing: self/context pointers
> and an extra error result. These are orthogonal to other arguments, and a
> function may have either or both of these special cases.
>
> * The “swiftself” attribute identifies an argument as the special “self”
> pointer (or the context for a closure). We pass this argument in a special
> dedicated register, at least for targets that have a register that can be
> used for that.
>
> * With Swift error handling, there is an extra return value that is
> returned in a special dedicated register (for targets that can support
> that). We represent this in LLVM IR using an argument with an extra level
> of indirection, kind of like what we do for “byval” arguments. There is a
> “swifterror" attribute on that argument. The IR for the function sets the
> error result by storing to that argument, but we actually generate code
> that returns the value directly in the dedicated register. There is also an
> attribute on the caller’s alloca that represents the error return value,
> since it is special in various ways, e.g., the value passed in doesn’t
> matter and doesn’t need to be initialized because it is really only a
> return value.
>
> Does that make sense?
>
>
> Ping.
>
> Eric, did you have any more concerns here? We should discuss this in more
> depth when the implementation of this calling convention can be shared.
> Reserving the constants now doesn’t hurt anything, does it? Even if we
> somehow end up with a different implementation later, we could free up
> those attribute values for other purposes at that time and we wouldn’t be
> any worse off than we would be otherwise.
>
>
Sure. I was worried about that part of it, but if we can back it out I have
no real concerns. I was curious about whether the attributes were actually
needed, but we can cover that later etc.

Thanks for checking and LGTM!

-eric


>
>
> Thanks!
>
> -eric
>
> On Wed, Jul 15, 2015 at 3:57 PM Bob Wilson <bob.wilson at apple.com> wrote:
>
>> As announced at WWDC, we are in the process of open-sourcing the Swift
>> compiler. In anticipation of that, I would like to apply the attached patch
>> to reserve some constant values to avoid incompatible bitcode between
>> Apple’s current Swift compiler and trunk. Swift has a custom calling
>> convention that also requires some new flags on arguments and one new
>> attribute on alloca instructions. This patch does not include the
>> implementation of that calling convention — that will be provided as part
>> of the open-source release of Swift; this only reserves the bitcode
>> constant values so that they are not used for other purposes on trunk,
>> which would make it impossible for people to use bitcode from the Xcode 7
>> Swift compiler with the version that we release as open-source.
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150727/50619a2b/attachment.html>