> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Easwaran Raman > Sent: Wednesday, June 24, 2015 9:54 AM > To: Xinliang David Li > Cc: <llvmdev at cs.uiuc.edu> List > Subject: Re: [LLVMdev] Inline hint for methods defined in-class > > Ping. > > On Wed, Jun 17, 2015 at 4:13 PM, Xinliang David Li <davidxl at google.com> > wrote: > > that looks like a different fix. The case mentioned by Easwaran is > > > > class A{ > > int foo () { return 1; } > > ... > > }; > > > > where 'foo' is not explicitly declared with 'inline' keyword. > > > > David > > > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> > wrote: > >> AFAIK, this was fixed in r233817.That was later reverted.> >> > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On > >> Behalf Of Easwaran Raman > >> Sent: Wednesday, June 17, 2015 6:59 PM > >> To: llvmdev at cs.uiuc.edu > >> Cc: David Li > >> Subject: [LLVMdev] Inline hint for methods defined in-class > >> > >> Clang adds the InlineHint attribute to functions that are explicitly > marked > >> inline, but not if they are defined in the class body. I tried the > following > >> patch, which I believe handles the in-class definition > >> case: > >> > >> --- a/lib/CodeGen/CodeGenFunction.cpp > >> +++ b/lib/CodeGen/CodeGenFunction.cpp > >> @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, > >> if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { > >> if (!CGM.getCodeGenOpts().NoInline) { > >> for (auto RI : FD->redecls()) > >> - if (RI->isInlineSpecified()) { > >> + if (RI->isInlined()) { > >> Fn->addFnAttr(llvm::Attribute::InlineHint); > >> break; > >> } > >> > >> I tried this on C++ benchmarks in SPEC 2006. There is no noticeable > >> performance difference and the maximum text size increase is < 0.25%. > >> I then built clang with and without this change. This increases the > text > >> size by 4.1%. For measuring performance, I compiled a large (4.8 > million > >> lines) preprocessed file. This change improves runtime performance by > 0.9% > >> (average of 10 runs) in O0 and O2. > >> > >> I think knowing whether a function is defined inside a class body is a > >> useful hint to the inliner. FWIW, GCC's inliner doesn't differentiate > these > >> from explicit inline functions. If the above results doesn't justify > this > >> change, are there other benchmarks that I should evaluate? Another > >> possibility is to add a separate hint for this instead of using the > existing > >> inlinehint to allow for better tuning in the inliner.A function with an in-class definition will have linkonce_odr linkage, so it should be possible to identify such functions in the inliner without introducing the inlinehint attribute. --paulr> >> > >> Thanks, > >> Easwaran > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Xinliang David Li
2015-Jun-24 19:56 UTC
[LLVMdev] Inline hint for methods defined in-class
The problem is that the other way around is not true: a function linkonce_odr linkage may be neither inline declared nor have in-class definition. David On Wed, Jun 24, 2015 at 11:53 AM, Robinson, Paul < Paul_Robinson at playstation.sony.com> wrote:> > > > -----Original Message----- > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On > > Behalf Of Easwaran Raman > > Sent: Wednesday, June 24, 2015 9:54 AM > > To: Xinliang David Li > > Cc: <llvmdev at cs.uiuc.edu> List > > Subject: Re: [LLVMdev] Inline hint for methods defined in-class > > > > Ping. > > > > On Wed, Jun 17, 2015 at 4:13 PM, Xinliang David Li <davidxl at google.com> > > wrote: > > > that looks like a different fix. The case mentioned by Easwaran is > > > > > > class A{ > > > int foo () { return 1; } > > > ... > > > }; > > > > > > where 'foo' is not explicitly declared with 'inline' keyword. > > > > > > David > > > > > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> > > wrote: > > >> AFAIK, this was fixed in r233817. > > That was later reverted. > > > >> > > >> -----Original Message----- > > >> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu > ] > > On > > >> Behalf Of Easwaran Raman > > >> Sent: Wednesday, June 17, 2015 6:59 PM > > >> To: llvmdev at cs.uiuc.edu > > >> Cc: David Li > > >> Subject: [LLVMdev] Inline hint for methods defined in-class > > >> > > >> Clang adds the InlineHint attribute to functions that are explicitly > > marked > > >> inline, but not if they are defined in the class body. I tried the > > following > > >> patch, which I believe handles the in-class definition > > >> case: > > >> > > >> --- a/lib/CodeGen/CodeGenFunction.cpp > > >> +++ b/lib/CodeGen/CodeGenFunction.cpp > > >> @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, > > >> if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { > > >> if (!CGM.getCodeGenOpts().NoInline) { > > >> for (auto RI : FD->redecls()) > > >> - if (RI->isInlineSpecified()) { > > >> + if (RI->isInlined()) { > > >> Fn->addFnAttr(llvm::Attribute::InlineHint); > > >> break; > > >> } > > >> > > >> I tried this on C++ benchmarks in SPEC 2006. There is no noticeable > > >> performance difference and the maximum text size increase is < 0.25%. > > >> I then built clang with and without this change. This increases the > > text > > >> size by 4.1%. For measuring performance, I compiled a large (4.8 > > million > > >> lines) preprocessed file. This change improves runtime performance by > > 0.9% > > >> (average of 10 runs) in O0 and O2. > > >> > > >> I think knowing whether a function is defined inside a class body is a > > >> useful hint to the inliner. FWIW, GCC's inliner doesn't differentiate > > these > > >> from explicit inline functions. If the above results doesn't justify > > this > > >> change, are there other benchmarks that I should evaluate? Another > > >> possibility is to add a separate hint for this instead of using the > > existing > > >> inlinehint to allow for better tuning in the inliner. > > A function with an in-class definition will have linkonce_odr linkage, > so it should be possible to identify such functions in the inliner > without introducing the inlinehint attribute. > --paulr > > > >> > > >> Thanks, > > >> Easwaran > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >> > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/90d8c7cb/attachment.html>
The method to identify functions with in-class definitions is one part of my question. Even if there is a way to do that without passing the hint, I'm interested in getting feedback on treating it at-par with functions having the inline hint in inline cost analysis. Thanks, Easwaran On Wed, Jun 24, 2015 at 12:56 PM, Xinliang David Li <xinliangli at gmail.com> wrote:> The problem is that the other way around is not true: a function > linkonce_odr linkage may be neither inline declared nor have in-class > definition. > > David > > > On Wed, Jun 24, 2015 at 11:53 AM, Robinson, Paul > <Paul_Robinson at playstation.sony.com> wrote: >> >> >> >> > -----Original Message----- >> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> > On >> > Behalf Of Easwaran Raman >> > Sent: Wednesday, June 24, 2015 9:54 AM >> > To: Xinliang David Li >> > Cc: <llvmdev at cs.uiuc.edu> List >> > Subject: Re: [LLVMdev] Inline hint for methods defined in-class >> > >> > Ping. >> > >> > On Wed, Jun 17, 2015 at 4:13 PM, Xinliang David Li <davidxl at google.com> >> > wrote: >> > > that looks like a different fix. The case mentioned by Easwaran is >> > > >> > > class A{ >> > > int foo () { return 1; } >> > > ... >> > > }; >> > > >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> > > >> > > David >> > > >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org> >> > wrote: >> > >> AFAIK, this was fixed in r233817. >> >> That was later reverted. >> >> > >> >> > >> -----Original Message----- >> > >> From: llvmdev-bounces at cs.uiuc.edu >> > >> [mailto:llvmdev-bounces at cs.uiuc.edu] >> > On >> > >> Behalf Of Easwaran Raman >> > >> Sent: Wednesday, June 17, 2015 6:59 PM >> > >> To: llvmdev at cs.uiuc.edu >> > >> Cc: David Li >> > >> Subject: [LLVMdev] Inline hint for methods defined in-class >> > >> >> > >> Clang adds the InlineHint attribute to functions that are explicitly >> > marked >> > >> inline, but not if they are defined in the class body. I tried the >> > following >> > >> patch, which I believe handles the in-class definition >> > >> case: >> > >> >> > >> --- a/lib/CodeGen/CodeGenFunction.cpp >> > >> +++ b/lib/CodeGen/CodeGenFunction.cpp >> > >> @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl >> > >> GD, >> > >> if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { >> > >> if (!CGM.getCodeGenOpts().NoInline) { >> > >> for (auto RI : FD->redecls()) >> > >> - if (RI->isInlineSpecified()) { >> > >> + if (RI->isInlined()) { >> > >> Fn->addFnAttr(llvm::Attribute::InlineHint); >> > >> break; >> > >> } >> > >> >> > >> I tried this on C++ benchmarks in SPEC 2006. There is no noticeable >> > >> performance difference and the maximum text size increase is < 0.25%. >> > >> I then built clang with and without this change. This increases the >> > text >> > >> size by 4.1%. For measuring performance, I compiled a large (4.8 >> > million >> > >> lines) preprocessed file. This change improves runtime performance by >> > 0.9% >> > >> (average of 10 runs) in O0 and O2. >> > >> >> > >> I think knowing whether a function is defined inside a class body is >> > >> a >> > >> useful hint to the inliner. FWIW, GCC's inliner doesn't differentiate >> > these >> > >> from explicit inline functions. If the above results doesn't justify >> > this >> > >> change, are there other benchmarks that I should evaluate? Another >> > >> possibility is to add a separate hint for this instead of using the >> > existing >> > >> inlinehint to allow for better tuning in the inliner. >> >> A function with an in-class definition will have linkonce_odr linkage, >> so it should be possible to identify such functions in the inliner >> without introducing the inlinehint attribute. >> --paulr >> >> > >> >> > >> Thanks, >> > >> Easwaran >> > >> _______________________________________________ >> > >> LLVM Developers mailing list >> > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
| The problem is that the other way around is not true: a function linkonce_odr linkage may be neither inline declared nor have in-class definition. Sorry, why is that a problem? Did you have some other reason to want to identify functions that either specify 'inline' or have an in-class definition? The inliner is not *prevented* from inlining a function that falls outside of those cases, as far as I know. A static file-level function might be a good candidate, even if it is not explicitly marked 'inline'. --paulr From: Xinliang David Li [mailto:xinliangli at gmail.com] Sent: Wednesday, June 24, 2015 12:56 PM To: Robinson, Paul Cc: Easwaran Raman; Xinliang David Li; <llvmdev at cs.uiuc.edu> List Subject: Re: [LLVMdev] Inline hint for methods defined in-class The problem is that the other way around is not true: a function linkonce_odr linkage may be neither inline declared nor have in-class definition. David On Wed, Jun 24, 2015 at 11:53 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu>] On > Behalf Of Easwaran Raman > Sent: Wednesday, June 24, 2015 9:54 AM > To: Xinliang David Li > Cc: <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>> List > Subject: Re: [LLVMdev] Inline hint for methods defined in-class > > Ping. > > On Wed, Jun 17, 2015 at 4:13 PM, Xinliang David Li <davidxl at google.com<mailto:davidxl at google.com>> > wrote: > > that looks like a different fix. The case mentioned by Easwaran is > > > > class A{ > > int foo () { return 1; } > > ... > > }; > > > > where 'foo' is not explicitly declared with 'inline' keyword. > > > > David > > > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org<mailto:bmakam at codeaurora.org>> > wrote: > >> AFAIK, this was fixed in r233817.That was later reverted.> >> > >> -----Original Message----- > >> From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu>] > On > >> Behalf Of Easwaran Raman > >> Sent: Wednesday, June 17, 2015 6:59 PM > >> To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> > >> Cc: David Li > >> Subject: [LLVMdev] Inline hint for methods defined in-class > >> > >> Clang adds the InlineHint attribute to functions that are explicitly > marked > >> inline, but not if they are defined in the class body. I tried the > following > >> patch, which I believe handles the in-class definition > >> case: > >> > >> --- a/lib/CodeGen/CodeGenFunction.cpp > >> +++ b/lib/CodeGen/CodeGenFunction.cpp > >> @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, > >> if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { > >> if (!CGM.getCodeGenOpts().NoInline) { > >> for (auto RI : FD->redecls()) > >> - if (RI->isInlineSpecified()) { > >> + if (RI->isInlined()) { > >> Fn->addFnAttr(llvm::Attribute::InlineHint); > >> break; > >> } > >> > >> I tried this on C++ benchmarks in SPEC 2006. There is no noticeable > >> performance difference and the maximum text size increase is < 0.25%. > >> I then built clang with and without this change. This increases the > text > >> size by 4.1%. For measuring performance, I compiled a large (4.8 > million > >> lines) preprocessed file. This change improves runtime performance by > 0.9% > >> (average of 10 runs) in O0 and O2. > >> > >> I think knowing whether a function is defined inside a class body is a > >> useful hint to the inliner. FWIW, GCC's inliner doesn't differentiate > these > >> from explicit inline functions. If the above results doesn't justify > this > >> change, are there other benchmarks that I should evaluate? Another > >> possibility is to add a separate hint for this instead of using the > existing > >> inlinehint to allow for better tuning in the inliner.A function with an in-class definition will have linkonce_odr linkage, so it should be possible to identify such functions in the inliner without introducing the inlinehint attribute. --paulr> >> > >> Thanks, > >> Easwaran > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev_______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/d644c622/attachment.html>
On Wed, Jun 24, 2015 at 12:56 PM, Xinliang David Li <xinliangli at gmail.com> wrote:> The problem is that the other way around is not true: a function > linkonce_odr linkage may be neither inline declared nor have in-class > definition. >The other common case where a linkonce_odr function will appear is when instantiating a function template. Now consider: struct X { void f() { /*...*/ } inline void g() { /*...*/ } }; and template<typename T> void f() { /*...*/ } template<typename T> inline void g() { /*...*/ } I think you're saying that the inline keyword should cause us to inline more aggressively in the template case but not in the inline-function-in-class-body case. That seems inconsistent to me (but not necessarily the wrong thing): in both cases, the definition of f was put into the header because it was convenient (or necessary), and not necessarily because the user was thinking about inlining, and in both cases the presence of the redundant 'inline' keyword seems like a hint that they want the function to be more aggressively inlined. Do we know whether the benefit we see by more aggressively inlining member functions defined within the class definition is actually because they're good candidates for inlining, or is it because inlining small functions more aggressively is a net win in general, and being defined inside the class is a good signal for "small function"? On Wed, Jun 24, 2015 at 11:53 AM, Robinson, Paul <> Paul_Robinson at playstation.sony.com> wrote: > >> >> >> > -----Original Message----- >> > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] >> On >> > Behalf Of Easwaran Raman >> > Sent: Wednesday, June 24, 2015 9:54 AM >> > To: Xinliang David Li >> > Cc: <llvmdev at cs.uiuc.edu> List >> > Subject: Re: [LLVMdev] Inline hint for methods defined in-class >> > >> > Ping. >> > >> > On Wed, Jun 17, 2015 at 4:13 PM, Xinliang David Li <davidxl at google.com> >> > wrote: >> > > that looks like a different fix. The case mentioned by Easwaran is >> > > >> > > class A{ >> > > int foo () { return 1; } >> > > ... >> > > }; >> > > >> > > where 'foo' is not explicitly declared with 'inline' keyword. >> > > >> > > David >> > > >> > > On Wed, Jun 17, 2015 at 4:07 PM, Balaram Makam <bmakam at codeaurora.org >> > >> > wrote: >> > >> AFAIK, this was fixed in r233817. >> >> That was later reverted. >> >> > >> >> > >> -----Original Message----- >> > >> From: llvmdev-bounces at cs.uiuc.edu [mailto: >> llvmdev-bounces at cs.uiuc.edu] >> > On >> > >> Behalf Of Easwaran Raman >> > >> Sent: Wednesday, June 17, 2015 6:59 PM >> > >> To: llvmdev at cs.uiuc.edu >> > >> Cc: David Li >> > >> Subject: [LLVMdev] Inline hint for methods defined in-class >> > >> >> > >> Clang adds the InlineHint attribute to functions that are explicitly >> > marked >> > >> inline, but not if they are defined in the class body. I tried the >> > following >> > >> patch, which I believe handles the in-class definition >> > >> case: >> > >> >> > >> --- a/lib/CodeGen/CodeGenFunction.cpp >> > >> +++ b/lib/CodeGen/CodeGenFunction.cpp >> > >> @@ -630,7 +630,7 @@ void CodeGenFunction::StartFunction(GlobalDecl >> GD, >> > >> if (const FunctionDecl *FD = dyn_cast_or_null<FunctionDecl>(D)) { >> > >> if (!CGM.getCodeGenOpts().NoInline) { >> > >> for (auto RI : FD->redecls()) >> > >> - if (RI->isInlineSpecified()) { >> > >> + if (RI->isInlined()) { >> > >> Fn->addFnAttr(llvm::Attribute::InlineHint); >> > >> break; >> > >> } >> > >> >> > >> I tried this on C++ benchmarks in SPEC 2006. There is no noticeable >> > >> performance difference and the maximum text size increase is < 0.25%. >> > >> I then built clang with and without this change. This increases the >> > text >> > >> size by 4.1%. For measuring performance, I compiled a large (4.8 >> > million >> > >> lines) preprocessed file. This change improves runtime performance by >> > 0.9% >> > >> (average of 10 runs) in O0 and O2. >> > >> >> > >> I think knowing whether a function is defined inside a class body is >> a >> > >> useful hint to the inliner. FWIW, GCC's inliner doesn't differentiate >> > these >> > >> from explicit inline functions. If the above results doesn't justify >> > this >> > >> change, are there other benchmarks that I should evaluate? Another >> > >> possibility is to add a separate hint for this instead of using the >> > existing >> > >> inlinehint to allow for better tuning in the inliner. >> >> A function with an in-class definition will have linkonce_odr linkage, >> so it should be possible to identify such functions in the inliner >> without introducing the inlinehint attribute. >> --paulr >> >> > >> >> > >> Thanks, >> > >> Easwaran >> > >> _______________________________________________ >> > >> LLVM Developers mailing list >> > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > >> >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150707/81ed8fed/attachment.html>