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