This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.


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

Re: Help: Unwinding the C++ stack...throw, longjmp & threads


>>>>> Richard Henderson <rth@cygnus.com> writes:

 > We should instead figure out why the 5% performance degradation
 > and fix it.

Agreed, though that isn't an option where we don't control libc.

 > IN THEORY, it shouldn't matter -- the complexity to compilation comes
 > when you have exception handlers, not throws.  We should not care that
 > some called function throws through any more than we care if they
 > longjmp though.

Agreed.

 > Probably it is the case that some pass that has yet to be 
 > converted to the properly use the new CFG is misinterpreting
 > basic block boundaries in the presence of flag_exceptions.

regmove.c says

      /* ??? We can't scan past the end of a basic block without updating
         the register lifetime info (REG_DEAD/basic_block_live_at_start).
         A CALL_INSN might be the last insn of a basic block, if it is
         inside an EH region.  There is no easy way to tell, so we just
         always break when we see a CALL_INSN if flag_exceptions is
         nonzero.  */

But as you say, this is unnecessary for code that contains no exception
regions, such as all C code.

That's the only case I found with a quick grep through the current
mainline.

Jason

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