[PATCH] D71219: Fix conflict value for metadata "Objective-C Garbage Collection" in the mix of swift and Objective-C bitcode

[Jin Lin via Phabricator via llvm-commits]

jinlin added a comment.

In D71219#1891857 <https://reviews.llvm.org/D71219#1891857>, @steven_wu wrote:

> In D71219#1890444 <https://reviews.llvm.org/D71219#1890444>, @jinlin wrote:
>
> > In D71219#1791936 <https://reviews.llvm.org/D71219#1791936>, @steven_wu wrote:
> >
> > > > 
> > > > 
> > > > 1. I will add a  llvm-link tests for combining objc and swift bitcode.
> > > > 2. What do you mean by "codegen tests for correct value in the object file"? There is no "object file" in the picture. Are you asking for a test that checks the value in the output of llvm-link?
> > >
> > > I think the decision was to break apart the current "Objective-C Garbage Collection" metadata. You need codegen test to test that OBJC_IMAGE_INFO is generated correctly after breaking apart the value.
> >
> >
> >
>


That is the thing I am confused.  For the merged bitcode, what OBJ_IMAGE_INFO should we generate in the assembly code?

>> I have question regarding this. Let's assume we have one assembly file from Objective-C and another one from Swift.
>> 
>> Objective-C assembly:
>> L_OBJC_IMAGE_INFO:
>> 
>>   	.long	0
>>   	.long	64
>> 
>> 
>> Swift assembly:
>> 
>> L_OBJC_IMAGE_INFO:
>> 
>>   	.long	0
>>   	.long	83953472
>> 
>> 
>> Let's assume that the llvm-link can link Swift bitcode and Objective-C bit successfully and the llc can generate the assembly for the merged output bitcode.
>> 
>> In the final assembly file, what value do you expect for L_OBJC_IMAGE_INFO?
> 
> You can easily test that out with ld64. It depends on the bits in the current garbage collection fields. Most of the fields are useless now (only there for GC which is obsoleted), that is why the module flag uses `Override`. Some bits in there are taking `Max`, like `OBJC_IMAGE_HAS_CATEGORY_CLASS_PROPERTIES`. Swift version should be taking `Error` since mismatch is a failure, unless it is not set.



> If you are breaking the module flag "Objective-C Garbage Collection" into all the corresponding bits, you can correctly specify all the right behavior for the bitfield.
> 
>> 
>> 
>>> 
>>> 
>>>> 3. Let us keep the auto upgrade to a different future diff to keep each diff self contained. Is that ok?
>>> 
>>> I disagree with that. That is leaving a gap for incompatible bitcode.
>>> 
>>> Steven



In D71219#1892292 <https://reviews.llvm.org/D71219#1892292>, @manmanren wrote:

> > We should add a new module flag (with type Error) that contains Major and Minor and make sure "Garbage Collection" value is the same for Swift as for ObjC.
> > 
> > In the backend, we will reconstruct IMAGE_INFO from the new module flags and make sure the value stays the same with and without this patch.
> > 
> > IMAGE_INFO will be different for Swift vs ObjC.
>
> Should be question mark! Meant for clarification from @steven_wu and @rjmccall. Should IMAGE_INFO include the value from the new module flag?





CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D71219/new/

https://reviews.llvm.org/D71219