[PATCH] Add target independent attribute for ObjCARC

[Richard Osborne]

On 17 May 2013, at 06:45, Bob Wilson <bob.wilson at apple.com> wrote:

> 
> On May 16, 2013, at 10:13 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On May 16, 2013, at 10:10 PM, Michael Gottesman <mgottesman at apple.com> wrote:
>> 
>>> On May 16, 2013, at 9:27 PM, Chris Lattner <clattner at apple.com> wrote:
>>> 
>>>> 
>>>> On May 16, 2013, at 5:58 PM, Michael Gottesman <mgottesman at apple.com> wrote:
>>>> 
>>>>> Hey Bill!
>>>>> 
>>>>> The attached patch adds a target independent attribute for ObjCARC.
>>>> 
>>>> Why?
>>> 
>>> Some context:
>>> \context
>>> We always run a certain ARC cleanup pass (ObjCARCContract) before codegen on code compiled with ARC. This creates a thorny issue when one is using LTO since we support the ability to mix MRR and ARC code together and we do not want to run ObjCARCContract on MRR code. The solution to this is to use Bill's attribute work to put an attribute on functions compiled in modules with ARC enabled and only run said pass during LTO codegen on functions which have said attribute. Thus we can mix/match modules that use ARC and those that use MRR.
>>> \end context
>>> 
>>> I have a patch on cfe-commits which adds this functionality as a string attribute (i.e. "objc-arc"). Bill suggested that I implement it as a target independent attribute (i.e. objcarc) implying this patch. I have no strong opinions here. As such if you have strong feelings about this, I have no problem using the string attribute. = ).
>> 
>> This doesn't make sense to me.  "ObjC ARC" is a language feature of one particular source language, not something that should be represented in IR.
>> 
>> If the problem is that the ARCContract pass shouldn't kick in on some libcalls (i.e., because they come from MRC code) have you considered using the extant "nobuiltin" attribute?
> 
> This was an attempt to simply transition to the new scheme of putting command-line options onto function attributes.  Currently the clang driver runs the ARC optimizer only when -fobjc-arc is used.  Running it for non-ARC code apparently breaks things, including the Objective C library code.  For LTO we are just running it all the time and hoping not to hit any of those cases.  Adding the attribute would be the most direct fix.
If it is bad to run the ARC optimizer on non-ARC code then won't you run into problems when non ARC functions are inlined into ARC functions?