[PATCH]: -fno-inline doesnt prevent inlining

Chandler Carruth chandlerc at google.com
Wed Jan 15 01:50:47 PST 2014


The more i think about it, the more I agree. =] I mostly agreed to start
with, so I figure this is a good sign. Sorry to slow things down, just
didn't want to take it for granted.


On Tue, Jan 14, 2014 at 4:17 PM, Reid Kleckner <rnk at google.com> wrote:

> I find the LTO argument compellingly in favor of using the NoInline
> attribute.
>
> On Tue, Jan 14, 2014 at 3:31 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
>> Are there strong reasons to do this by adding attributes rather than
>> changing the optimizer's behavior? I'm uncertain.
>>
>> On one hand, it would be more efficient in the optimizer to just switch
>> to the always-inliner pass.
>>
>> On the other hand, if we are doing an LTO build, adding attributes
>> ensures that even the link-top inline step doesn't inline those functions.
>>
>> On the other other hand, if we are doing an LTO build, we might want to
>> only prevent inlining during the per-TU optimization run, not during the
>> LTO optimization run.
>>
>> Thoughts?
>>
>>
>> On Tue, Jan 14, 2014 at 11:58 AM, Roman Divacky <rdivacky at freebsd.org>wrote:
>>
>>> Hi,
>>>
>>> Currently -fno-inline doesnt do much, it just prevents adding InlineHint
>>> attributes. This means that we differ from gcc which prevents all
>>> functions (except always_inline) from inlining. This simple patch
>>> implements that behaviour, is that ok?
>>>
>>> Index: lib/CodeGen/CodeGenFunction.cpp
>>> ===================================================================
>>> --- lib/CodeGen/CodeGenFunction.cpp     (revision 199224)
>>> +++ lib/CodeGen/CodeGenFunction.cpp     (working copy)
>>> @@ -510,7 +510,7 @@
>>>
>>>    // Pass inline keyword to optimizer if it appears explicitly on any
>>>    // declaration.
>>> -  if (!CGM.getCodeGenOpts().NoInline)
>>> +  if (!CGM.getCodeGenOpts().NoInline) {
>>>      if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
>>>        for (FunctionDecl::redecl_iterator RI = FD->redecls_begin(),
>>>               RE = FD->redecls_end(); RI != RE; ++RI)
>>> @@ -518,6 +518,10 @@
>>>            Fn->addFnAttr(llvm::Attribute::InlineHint);
>>>            break;
>>>          }
>>> +  } else if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D))
>>> +    if (!FD->hasAttr<AlwaysInlineAttr>() &&
>>> +        !FD->hasAttr<ForceInlineAttr>())
>>> +      Fn->addFnAttr(llvm::Attribute::NoInline);
>>>
>>>    if (getLangOpts().OpenCL) {
>>>      // Add metadata for a kernel function.
>>> Index: test/CodeGen/noinline.c
>>> ===================================================================
>>> --- test/CodeGen/noinline.c     (revision 199224)
>>> +++ test/CodeGen/noinline.c     (working copy)
>>> @@ -7,6 +7,7 @@
>>>
>>>  volatile int *pa = (int*) 0x1000;
>>>  void foo() {
>>> +// NOINLINE: Function Attrs: noinline
>>>  // NOINLINE: @foo
>>>  // NOINLINE: dont_inline_me
>>>  // NOINLINE-NOT: inlinehint
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>>
>>
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140115/da2aed4a/attachment.html>


More information about the cfe-commits mailing list