search for: sawpotentiallythrow

I have a question concerning the exception handling tables that we generate. Right now we generate call sites for all of the code in a function, even for code that cannot (or at least shouldn't) throw an exception. E.g., for this code: #include <cstdio> struct Cleanup { ~Cleanup(void) { printf("in cleanup\n"); } }; static void inline_me(void) {

Hi Bill, > The reason to ask this is that >> it could make the EH tables smaller and less cluttered if we elide >> those areas which we know don't throw (the functions called are marked >> 'nounwind', etc.). > > Sure, that's what the SawPotentiallyThrowing boolean is for. It is > currently set for any call, but in fact needn't be set for 'nounwind' > calls. When I wrote this stuff 'nounwind' information wasn't available > at the codegen level, which is why this isn't done. In case you care, > doing this w...

On Sep 17, 2009, at 6:03 PM, Duncan Sands wrote: > Hi Bill, > >>>> Yeah. The logic will need tweaking for sure. I'm also concerned >>>> about the >>>> _Unwind_resume() call. GCC emits a call site region for it in the >>>> exception >>>> table. We...kind of do that. It looks like it's being included in >>>>

...lls, i.e. things you want to catch in this function. The reason to ask this is that > it could make the EH tables smaller and less cluttered if we elide > those areas which we know don't throw (the functions called are marked > 'nounwind', etc.). Sure, that's what the SawPotentiallyThrowing boolean is for. It is currently set for any call, but in fact needn't be set for 'nounwind' calls. When I wrote this stuff 'nounwind' information wasn't available at the codegen level, which is why this isn't done. In case you care, doing this would not hurt Ada :)...

...Bill, > >> The reason to ask this is that >>> it could make the EH tables smaller and less cluttered if we >>> elide those areas which we know don't throw (the functions called >>> are marked 'nounwind', etc.). >> Sure, that's what the SawPotentiallyThrowing boolean is for. It is >> currently set for any call, but in fact needn't be set for 'nounwind' >> calls. When I wrote this stuff 'nounwind' information wasn't >> available >> at the codegen level, which is why this isn't done. In case you...