llvm dev - Sep 2015 - inlining in exception handing region

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
>

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
>
>