| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
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.