[llvm-dev] Exception handling support for a target

[David Chisnall via llvm-dev]

On 19 Jan 2018, at 14:48, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> OpenVMS' EH model is for full asynchronous prologue/epilogue EH.  We do more
> than just program-level EH, but have to deal with OS events (timers going off, 
> asynch I/O completion, mailboxes filled with data, etc.) which could result in
> an unwind occurring.   
> 
> We're just about finished with our proposal for extending the x86 compact EH data 
> format to cover all the cases plus the desire to create the additional .cfi directives.  
> Feedback and pointers will be most helpful.  Look for this as a new thread sometime 
> early next week (we're having our final review on Monday before I post it).

Are you planning on extending LLVM to add support for non-call exceptions?  Currently, LLVM is not able to produce correct unwind tables for arbitrary exception points because it does not split basic blocks in such a way that values that are created in a basic block will be visible in at the end.  For example, if I do 

int i = 0;
try {
  i++;
  foo();
  i++;
} catch (…) {
  return i;
}

The SSA form of this will look something more like this:

int i0 = 0;
try {
  i1 = 1;
  foo();
  i2 = 2;
} catch (…) {
  return 1;
}

But if you are allowed to throw exceptions on any instruction, then you end up with something more like:

int i0 = 0;
try {
a:
  i1 = 1;
b:
  foo();
c:
  i2 = 2;
} catch (…) {
  return phi({a,0},{b, i1},{c,i2});
}

With the current structure of LLVM’s exception handling, the fact that i may be incremented after the only invoke instruction is not visible.

I’ve never been entirely happy with how LLVM models exceptions, as calls with two possible returns, but extending that model to properly support unwinds through arbitrary instructions will leave us in the degenerate case of having single-instruction basic blocks.  I’d much rather that we split blocks on places where values visible in an exception handler change, rather than on specific places where exceptions are known to be thrown, but this will require moving to a region-based representation of exceptions, which is a lot of work.  Without this, it’s easy to unwind from arbitrary exceptions, unless you care about having the right values in your handlers.

David