[J3] [EXTERNAL] Re: Exception handling - Golang proposal

[Robert Corbett]

It is certainly possible to design exception handling mechanisms that do not seriously interfere with compiler optimizations.  Any such mechanism is likely to be more restricted than many existing exception handling mechanisms.  Some scripting languages support powerful exception handling mechanisms.  They also do no code optimization and have complete control over their execution stacks.

Even a simple static exception handling mechanism can create problems for optimization.  Each point in the program where an exception might occur becomes a sequence point, which can block code motion and adds branches to the control flow graph (CFG).  The size of the CFG can significantly affect the space and time required for optimizations.

In the real world, there can be other obstacles to efficiently implementing exception handling.  In my previous life (before I retired), I supported Fortran in environments that were hostile to Fortran.  The Fortran compilers I supported used code generators that were primarily designed to generate code for C and C++.  The code generation teams had enough to do supporting those languages.  Asking for support for a new feature that would benefit only Fortran would be futile.

Bob Corbett

> On Jul 24, 2019, at 1:53 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
>> On Wed, 2019-07-24 at 14:46 -0600, Ondřej Čertík via J3 wrote:
>> As the Golang proposal mentions, it might not be worth doing, but I
>> think it's a clean solution that would not preclude the compiler from
>> doing optimizations, which many of the traditional exception
>> mechanisms would. And so it is worth considering the Pros and Cons.
> 
> I keep hearing the opinion that block-structured exception handling
> interferes with optimization.  My contacts in the Ada community say
> that's nonsense.  Maybe developers of other languages' compilers just
> haven't figured it out.
> 
> If the semantic description of block-structured exception handling in
> the standard for some language inevitably results in optimization
> problems, I'd be interested to know what those specifications are,
> rather than vague handwaving -- that has been contradicted by people who
> have done it well.
> 
>