mirgen: lower finally

[zerbina]

Summary

• simplify MIR control-flow constructs
• lower finally into a block + case dispatcher in mirgen
• emit exception stack management code in mirgen already
• inline scope cleanup directly at break and return

Details

The goals are to:

• use a unified exception runtime across all backends
• make the MIR simpler
• reduce the complexity of the language reaching the code generators,
  and thus the amount of translation work for the code generators

For the MIR:

• target lists are removed; jumps only need to specify a single target
• Finally can only be used as the target for exceptional jumps;
  unstructured control-flow out of a Finally section is disallowed
• only a single exceptional target can be specified for Continue
• Raise is decoupled from exception management; it only initiates
  unwinding now

The various MIR processing, rendering, and translation is adjusted
accordingly. The CGIR equivalents to the MIR constructs change in the
same way.

Since Finally can no longer be used with non-exceptional control-flow
(Goto, Case, etc.), translation of both scope cleanup and finally
needs to change in mirgen. The exception runtime calls for managing
the exception stack also have to be injected in mirgen already.

finally Lowering

finally is translated into continuation passing. However, instead of
reifying the finally into a standalone procedure, all "invocations"
of (read, jumps to) the finally record their original destination in
a local variable, which a dispatcher emitted at the end of the
finally clause then uses to jump to the target (or another
intercepting finally).

Scope Cleanup

Scope cleanup in response to an exception being raised still uses
Finally. For cleanup in response to break or return, all
necessary cleanup is emitted directly before the Goto. This increases
the workload for the move analysis / destructor elision pass, but it
also results in more efficient code (since there are usually less
dynamic invocations of destructors).

Code Generation

All three code generators are updated to consider the new syntax and
semantics of Finally, Continue, etc. Notably:

• ccgflow is obsolete and thus removed; code generation for
  Finally, Continue, etc. is now simple enough to implement
  directly in cgen
• jsgen now translates Finally to a JavaScript catch clause (so
  as to not interfere with breaks), which simplifies code generation
  (no more enabling/disabling of finally clauses for breaks) and
  also improves code size / performance in some cases

Exception Runtime

• nimAbortException has a viaRaise parameter now, as the C-specific
  error flag cannot be used anymore for detecting what causes the abort
• prepareException is merged back into raiseExceptionAux

The JavaScript target also using the C exception runtime now fixes a
bug where breaking out of a finally didn't clean up the current
exception properly.

VM

Exception stack management is partially decoupled from the core VM and
moved to vmops (which hooks and implements the various exception
runtime procedures). Generating the stacktrace still needs to be done
directly by the VM, which prevents the exception stack management from
being fully decoupled.

[zerbina]

A MIR Finally is only usable for intercepting exceptional control-flow now, and thus it cannot be used for destructor calls anymore. For implementing scope cleanup, one possible solution would have been to keep the merged destructor blocks and use dispatchers (which is what ccgflow previously did, in the end), but I opted for inlining the destructors directly at the gotos instead.

To visualize what I mean, consider the following:

block L1:
  var x = ...
  if ...: break L1
  var y = ...
  if ...: break L1

Previously, this resulted in MIR code that is equivalent to:

block L1:
  var x = ...
  try:
    if ...: break L1
    var y = ...
    try:
      if ...: break L1
    finally:
      `=destroy`(y)
  finally:
    `=destroy`(x)

Now, the generated MIR code is equivalent to:

block L1:
  var x = ...
  if ...:
    `=destroy`(x)
    break L1
  var y = ...
  if ...:
    `=destroy`(y)
    `=destroy`(x)
    break L1
  `=destroy`(y)
  `=destroy`(x)

While both are functionally equivalent, the inlined version allows for more static elision of =destroy calls and destructive moves (wasMoved), thus possibly reducing run-time overhead.

---

I made a test with the compiler code-base in order to get some concrete performance numbers. Let A be the compiler from fb4665a (devel, at the time of writing). Let B be the compiler from this PR.

Using a -d:release version of A that was built by A, the time it takes to compile A is:

Time (mean ± σ):     14.955 s ±  0.156 s

Using a -d:release version of A that was built by B, the time it takes to compile A is:

Time (mean ± σ):     14.641 s ±  0.047 s

[saem]

one design question, but looks good

[saem]

Silly question, would it be possible to specify this upfront as part of the finally block as Finally <label> <EX_TARGET>, seems like one less thing to remember?

[zerbina]

It's not a silly question, and it's also something that I had considered.

The reason I decided against it is that in general, processing needs to know the follow-up target upon visiting the mnkContinue and not when visiting the mnkFinally. Good examples for this are mirexec (generating a data-flow graph from the MIR code), cgen, and jsgen. Having the follow-up target on the Finally statement would require some additional state in those cases.

[zerbina]

/merge

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---

Note For Reviewers

• reviewing the commits individually is likely going to be easier than reviewing everything together