[TUHS] v7 K&R C

[Paul Winalski]

On 5/12/20, ron at ronnatalie.com <ron at ronnatalie.com> wrote:
>> On 5/11/20, Larry McVoy <lm at 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.

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.