13 May
2020
13 May
'20
12:36 a.m.
On 5/12/20, ron(a)ronnatalie.com <ron(a)ronnatalie.com> wrote:
The C++ standard libraries make heavy use of throw/catch exception
handling. If routine A calls routine B, and B is known by the
compiler to have the capability to throw exceptions, a bunch of
important optimizations can't be done. For example:
o You can't keep global values in registers around the call to B
because the handler that catches an exception that B throws might use
that global variable. So you have to spill the value around the call.
o You can't do value propagation of global variables around the call
to B because a handler might change their values.
And it gets a lot worse when you start doing parallel loop execution.
I implemented a new design for exception handling in a C/C++ compiler
back end, and I found lots of corner cases where the C++ standard was
silent as to what should happen when exceptions are thrown or caught
from parallel threads. Things such as the order of execution of
constructors and destructors for parallel routines when a thrown
exception is unwound, and which side of the parallelization executes
constructors and destructors under those conditions. The committee
just plain never considered those issues.
-Paul W.
On 5/11/20,
Larry McVoy <lm(a)mcvoy.com> wrote:
o all std:: and STL functions
The last two of these are mainly for performance reasons. throw and
catch play merry hell with compiler optimizations, especially of
global variables.
You'll have to explain to me how templates or the standard library (which
by the way includes all of the C stuff) affects performance. In fact, we
use templates to INCREASE rather than decrease performance. Templating
is almost entirely compile time rewrites.