Re: My plans on EH infrastructure

[Jan Hubicka <hubicka at ucw dot cz>]

> 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.
I have no idea how much performance it adds, but cleanups that optimize
to nothing are quite common so it might show up in code that is bound in
performance by EH delivery speed (I don't expect this is that common,
right?)

> >- the catch clause contains the throw (after inlining).
>        ^^^^^^^^^^^^
> I meant the try block, sorry.

"inlining" throw() call is another item I forgot on my list.  My EH-fu
is not exactly on par here. I see no reason why we can't convert throw() call
into FILTER_EXPR/OBJ_REF_EXPR set and RESX when RESX will be turned into
direct goto. It is also something I wanted to experiment with.

This has potential to improve C++ code especially by turning functions
leaf and cheaper for inlining. Definitly on tramp there are such cases.
One thing I worry about is that this effectivly makes it impossible to
breakpoint on throw that might be common thing C++ users want to see
working.  This can probably be partly fixed by emitting proper dwarf for
inlined function around the RESX, but GDB won't use it at a moment for
breakpointing anyway.

We also should get profile estimates more precise here by knowing that
certain calls must throw.  We are completely wrong here by basically
assuming that EH is never taken.
> 
> >- interprocedural analysis can connect the throwing spot and
> > the corresponding catch clause.
> >?

One can work out interprocedurally where the exception will be caught,
but what one can do about this info?  Translating it to nonlocal goto
is overkill because of colateral damage nonlocal goto
infrastructure would bring on the non-throwing path.  If EH delivery
mechanizm has to be used, we are pretty much going as far as we can
here.  In the throwing function we work out there is no local catch
block and in the callers similarly.

Pure-const pass can probably be improved to, in addition to mark NOTHROW
function to also work out list of types of exceptions.  Has this chance
to help?

Also if you are aware of EH heavy codebase that can be nicely
benchmarked, it would be interesting to consider adding it into our C++
benchmark suite.  We don't cover this aspect at all.
I would be interested in real code that has non-trivial EH that is not
bound by the EH delivery performance, but to also see how much the EH
code slows down the non-EH paths.

Honza
> >
> >See my old PR 6588.  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6588
> >
> 
> 
> -- 
> Sylvain Pion
> INRIA Sophia-Antipolis
> Geometrica Project-Team
> CGAL, http://cgal.org/