I observed about +6% performance improvement in one of c++ tests in spec2006 in AArch64 by avoiding inlining functions in exception handling region. I guess this is not really rare because programers often make small methods with throw statement like fCallee() in below sample c++ code. Thanks, Jun> Hi Jun, > > It's a very common that C++ exception handling code blow up the inlining > cost of the a function. > > It became more when compiler inlines calls in exception handling code. > > As exception handling code executes very rarely, you can apply some > heuristic in inliner to avoid inlining > for calls in exception region. By this it will open up more inlining > opportunities. > > I'm not sure how much this will help, as these cases are very rare. > > How do you justify gains of this, do you have any data ? > > Regards, > Ashutosh > > -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via > llvm-dev > Sent: Saturday, September 12, 2015 12:54 AM > To: llvm-dev at lists.llvm.org > Subject: [llvm-dev] inlining in exception handing region > > Hello, > > While I was investigating C++ benchmarks, I was aware of that some small > functions with the throw statement were not inlined because the exception > handling code increased the inline cost. In the c++ example below, the > inline cost of fCallee is high mainly because of instructions for the > throw statement, and note that the constructor of MyException is even > inlined in fCallee. > > Assuming that the exception handling code is rarely executed, would it > make sense to prevent CallSites in exception handling region (e.g., the > constructor of MyException) from being inlined so that we can avoid code > size blow-up in exception handling region and indirectly give more > inlining opportunity to the small unwinding functions containing > exception > handling code? > > class MyBaseException { > int idx; > int limit; > const char* msg; > public : > MyBaseException(int i, int l, const char* m); > ~MyBaseException(); > void handle(const char*m, int i, int l); > }; > > class MyException : MyBaseException > { > public: > MyException(int i, int l, const char* m): MyBaseException(i, l, m) { > handle(m, i, l); > } > }; > > int *Agg; > > int fCallee(int idx, int limit) { > if (idx >= limit) > throw MyException(idx, limit, "error"); > return Agg[idx]; > } > > int fCaller(int i, int l) { > return fCallee(i, l); > } > > Thanks, > Jun > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Philip Reames via llvm-dev
2015-Sep-14 18:49 UTC
[llvm-dev] inlining in exception handing region
I'm interested in this idea, but I want to point out that this is simply one special case of a static heuristics for estimating call frequency. This is essentially applying profile guided optimization style logic based on a static heuristic about hotness of code. I'm not saying this to dismiss it, merely to help frame it in context of things already being discussed and considered for the inliner. How is your patch structured w.r.t. exception handling region detection in the caller during inlining? That seems like it will be the critical design point. Philip On 09/14/2015 11:01 AM, via llvm-dev wrote:> I observed about +6% performance improvement in one of c++ tests in > spec2006 in AArch64 by avoiding inlining functions in exception handling > region. I guess this is not really rare because programers often make > small methods with throw statement like fCallee() in below sample c++ > code. > > Thanks, > Jun > > >> Hi Jun, >> >> It's a very common that C++ exception handling code blow up the inlining >> cost of the a function. >> >> It became more when compiler inlines calls in exception handling code. >> >> As exception handling code executes very rarely, you can apply some >> heuristic in inliner to avoid inlining >> for calls in exception region. By this it will open up more inlining >> opportunities. >> >> I'm not sure how much this will help, as these cases are very rare. >> >> How do you justify gains of this, do you have any data ? >> >> Regards, >> Ashutosh >> >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of via >> llvm-dev >> Sent: Saturday, September 12, 2015 12:54 AM >> To: llvm-dev at lists.llvm.org >> Subject: [llvm-dev] inlining in exception handing region >> >> Hello, >> >> While I was investigating C++ benchmarks, I was aware of that some small >> functions with the throw statement were not inlined because the exception >> handling code increased the inline cost. In the c++ example below, the >> inline cost of fCallee is high mainly because of instructions for the >> throw statement, and note that the constructor of MyException is even >> inlined in fCallee. >> >> Assuming that the exception handling code is rarely executed, would it >> make sense to prevent CallSites in exception handling region (e.g., the >> constructor of MyException) from being inlined so that we can avoid code >> size blow-up in exception handling region and indirectly give more >> inlining opportunity to the small unwinding functions containing >> exception >> handling code? >> >> class MyBaseException { >> int idx; >> int limit; >> const char* msg; >> public : >> MyBaseException(int i, int l, const char* m); >> ~MyBaseException(); >> void handle(const char*m, int i, int l); >> }; >> >> class MyException : MyBaseException >> { >> public: >> MyException(int i, int l, const char* m): MyBaseException(i, l, m) { >> handle(m, i, l); >> } >> }; >> >> int *Agg; >> >> int fCallee(int idx, int limit) { >> if (idx >= limit) >> throw MyException(idx, limit, "error"); >> return Agg[idx]; >> } >> >> int fCaller(int i, int l) { >> return fCallee(i, l); >> } >> >> Thanks, >> Jun >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
I agree that this could be seen as a special case of inlining in cold region. However, I doubt if we need to see this only in the context of PGO. I guess, in general, considering exception handing code as cold is not unreasonable even without relying on profiling. Regarding detecting exception handing region, I'm relying on getting hints from standard function name such as __cxa_allocate_exception". Please let me know if anyone has any better idea about it. Thanks, Jun> I'm interested in this idea, but I want to point out that this is simply > one special case of a static heuristics for estimating call frequency. > This is essentially applying profile guided optimization style logic > based on a static heuristic about hotness of code. I'm not saying this > to dismiss it, merely to help frame it in context of things already > being discussed and considered for the inliner. > > How is your patch structured w.r.t. exception handling region detection > in the caller during inlining? That seems like it will be the critical > design point. > > Philip > > On 09/14/2015 11:01 AM, via llvm-dev wrote: >> I observed about +6% performance improvement in one of c++ tests in >> spec2006 in AArch64 by avoiding inlining functions in exception handling >> region. I guess this is not really rare because programers often make >> small methods with throw statement like fCallee() in below sample c++ >> code. >> >> Thanks, >> Jun >> >> >>> Hi Jun, >>> >>> It's a very common that C++ exception handling code blow up the >>> inlining >>> cost of the a function. >>> >>> It became more when compiler inlines calls in exception handling code. >>> >>> As exception handling code executes very rarely, you can apply some >>> heuristic in inliner to avoid inlining >>> for calls in exception region. By this it will open up more inlining >>> opportunities. >>> >>> I'm not sure how much this will help, as these cases are very rare. >>> >>> How do you justify gains of this, do you have any data ? >>> >>> Regards, >>> Ashutosh >>> >>> -----Original Message----- >>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of >>> via >>> llvm-dev >>> Sent: Saturday, September 12, 2015 12:54 AM >>> To: llvm-dev at lists.llvm.org >>> Subject: [llvm-dev] inlining in exception handing region >>> >>> Hello, >>> >>> While I was investigating C++ benchmarks, I was aware of that some >>> small >>> functions with the throw statement were not inlined because the >>> exception >>> handling code increased the inline cost. In the c++ example below, the >>> inline cost of fCallee is high mainly because of instructions for the >>> throw statement, and note that the constructor of MyException is even >>> inlined in fCallee. >>> >>> Assuming that the exception handling code is rarely executed, would it >>> make sense to prevent CallSites in exception handling region (e.g., the >>> constructor of MyException) from being inlined so that we can avoid >>> code >>> size blow-up in exception handling region and indirectly give more >>> inlining opportunity to the small unwinding functions containing >>> exception >>> handling code? >>> >>> class MyBaseException { >>> int idx; >>> int limit; >>> const char* msg; >>> public : >>> MyBaseException(int i, int l, const char* m); >>> ~MyBaseException(); >>> void handle(const char*m, int i, int l); >>> }; >>> >>> class MyException : MyBaseException >>> { >>> public: >>> MyException(int i, int l, const char* m): MyBaseException(i, l, m) >>> { >>> handle(m, i, l); >>> } >>> }; >>> >>> int *Agg; >>> >>> int fCallee(int idx, int limit) { >>> if (idx >= limit) >>> throw MyException(idx, limit, "error"); >>> return Agg[idx]; >>> } >>> >>> int fCaller(int i, int l) { >>> return fCallee(i, l); >>> } >>> >>> Thanks, >>> Jun >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >