[llvm-dev] inlining in exception handing region

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