[PATCH] Add target independent attribute for ObjCARC

[John McCall]

On May 16, 2013, at 10:45 PM, 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:
>>>>> 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 we can get clang to put "nobuiltin" attributes on those calls, that would be a nice alternative.  John, what do you think?

I almost agree that using 'nobuiltin' on call sites makes sense.  The problem is that the polarity of 'nobuiltin' is really backwards;  there should be a 'builtin' attribute that opts in to optimizations instead of requiring frontends to opt out.  In other words, the IR shouldn't be designed such that every non-ARC frontend has a latent bug if they happen to call a function that's named the same as an ARC entrypoint.

This would be less of an immediate problem if the ARC passes weren't just unconditionally enabled by default in the optimizer pipeline, of course (or is that just for LTO?).

John.