[llvm-dev] inlining in exception handing region

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 14 11:49:50 PDT 2015


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



More information about the llvm-dev mailing list