[PATCH] Attach "objc-arc" function attribute to function definitions compiled in a module with ARC enabled.

[Bob Wilson]

On May 15, 2013, at 3:39 PM, jahanian <fjahanian at apple.com> wrote:

> 
> On May 15, 2013, at 2:27 PM, Michael Gottesman <mgottesman at apple.com> wrote:
> 
>> Hey Fariborz!
>> 
>> I think that predicating this on LTO may be the wrong thing to do [but please correct me if I am wrong as always = )].
>> 
>> Specifically, the use case for this attribute is to not run ARC optimization passes when a function does not have an ``objc-arc'' attribute on it during the post transformation stage of LTO. If we predicate this attribute on LTO being enabled, the arc optimizer passes would necessarily need to know to not look for the attribute when LTO is disabled and to look for the attribute when LTO is enabled. Currently none of the optimization passes know whether or not they are being used to optimize IR for LTO; An optimization pass just optimizes IR (a de facto invariant).
>> 
>> As such, no plumbing currently exists in LLVM for optimization passes to know whether or not they are being used in an LTO setting. I am unsure if this use case would justify adding that plumbing and additionally if allowing the passes to do that would open up all sorts of cans of worms.
>> 
>> Tell me what you think,
> 
> It makes sense under the scenario you outlined. I am not sure what the overhead of carrying this attribute in the IR is. Probably not much.

The idea is that we will move all command-line options that affect the backend to function attributes.  This is motivated by LTO but will also help clean up the interface between clang and the backend.  Bill has been working on this for a while, and the overall approach has already been extensively discussed and reviewed.

Bill, can you take a look at Michael's patch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130515/175d31cb/attachment.html>