This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: My plans on EH infrastructure


> Jan Hubicka a écrit :
> >>Sylvain Pion a écrit :
> >>>Naive user question : is this going to improve the efficiency
> >>>of throwing exceptions, at least in the restricted cases of :
> >
> >There is little improvement already via EH cleanup: at least
> >cleanups/catch regions that turns out to be empty are now eliminated and
> >does not slow down unwinding process.
> 
> It will probably not help for the synthetic benchmark case of PR 6588
> (try { throw(0); } catch(...) {}), since this case has nothing to be
> cleaned up, right?  Not that I care about this synthetic case, but
Right.
> even if the case which has nothing to clean up nor unwinding is already
> too slow...

> EH throwing is so costly (20000 cycles minimum reported in PR 6588) that,
> in some cases, even if it's exceptional, like a 10^-4 probability
> of throwing, you will see it show up on the profile.
> 
> Having EH delivery at reasonnable speed would really open up the design
> space : it would allow to use a non-intrusive way of reporting "exceptional"
> return values in many more places.  By non-intrusive, I mean that you
> don't need to change the return type of your functions and manually
> propagate your exceptional return values (or worse, use global or
> thread-local variables).

Problem here is that EH delivery mechanizm is part of C++ ABI.  The
mechanizm is indeed compicated.  I am sure runtime can be optimized, but
probably not made something like thousdand times faster than it is now.

So if we start optimizing special cases of EH to be fast, it will not
allow users to use it in performance critical stuff since they will
never know if they hit the fast or slow path and will only get
surprises.

We can implement interprocedural pass that will identify EH that is
delievred locally in the unit and use alternative EH delivery mechanizm,
but it would be a lot of effort to implement faster variant of runtime
that works on so many targets as GCC has and the benefits would be IMO
quite low.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]