[PATCH] reserve constants for Swift bitcode compatibility

[Bob Wilson]

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

> 
>> 
>> Thanks!
>> 
>> -eric
>> 
>> On Wed, Jul 15, 2015 at 3:57 PM Bob Wilson <bob.wilson at apple.com <mailto: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 <mailto:llvm-commits at cs.uiuc.edu>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits <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/20150725/64cf3138/attachment.html>