User: Password:
|
|
Subscribe / Log in / New account

Not quite

Not quite

Posted Mar 27, 2008 16:13 UTC (Thu) by BenHutchings (subscriber, #37955)
In reply to: Not quite by wahern
Parent article: Striking gold in binutils

Most C++ implementations use range tables for exception handling today, so no extra code is
needed in the function prologue or the non-exception epilogue. The possibility of a callee
throwing can constrain optimisation of the caller, but so does explicit error checking.


(Log in to post comments)

Not quite

Posted Mar 27, 2008 20:35 UTC (Thu) by wahern (subscriber, #37304) [Link]

From my limited research, it seems the constraint is much more in C++, because C++ must
preserve stack state (minimally, the mere existence of an activation record), whereas in C a
compiler can obliterate any evidence of a function call, no matter whether or how the return
value is used. Granted, I'm not aware of what kind of requirements the C++ standard mandates;
certainly I'd bet in non-conforming mode a compiler could cheat in this respect. I'd like to
hear some analysis on this.

Inlining in general, though, is actually important, because in C one of the biggest fixed
costs you have to keep in mind is function call. As shown in my example else thread, there's
comparatively quite a lot of work to maintain the stack. This is, of course, a big deal in
most other languages, too. If you've ever written much PerlXS (and peered behind the macros),
at some point it dawns on you how much work is being done to maintain the stack--it's
incredible! The fixed costs of maintaining call state in Perl dwarfs most everything
else--excepting I/O or process control--including manipulation of dynamically typed objects.

Not quite

Posted Mar 27, 2008 22:28 UTC (Thu) by ncm (subscriber, #165) [Link]

For the record, nothing about exceptions in the C++ standard or common implementation methods
interferes with inlining.  In practice, the body of an inlined function is just merged into
the body of whatever non-inline function it's expanded in.

The only place where exceptions interfere with optimization is in that the state of a function
context at a call site must be discoverable by the stack unwinder, so it can know which
objects' destructors have to run.  In practice this means that calls in short-circuited
expressions, e.g. "if (a() && b()) ...", sometimes also set a flag: "if (a() && ((_f=1),b()))
...".  This only happens if b() returns an object with a destructor, i.e. rarely.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds