[LLVMdev] Requirements for the EH representation

[Charllls Alquarra]

--- wednesday 11-may-11, John McCall <rjmccall at apple.com> wrote:

> > 
> > However, it has always seemed to me that exception
> handling (at least on c++) is just a particular syntax of a
> subset of coroutine semantics:
> 
> This is certainly one way of implementing exceptions. 
> Unfortunately, it would be prohibitively expensive to create
> a new coroutine every time a new EH scope is entered —
> much worse than other explicit scope-tracking
> implementations like SEH or builtin_sj/lj.

I completely agree on this, but it seems to me that all the exception
specific context switchs are no more than a list of specific optimization scenarios where one can trim certain aspects of the context switch.

It seems to me that the idea of language-specific exceptions is a too high level concept to be embedded in a compiler toolkit. Your post seemed to me to represent the right intentions regarding design goals; trying to keep the exception system as general as possible

My post only purpose was to highlight that in regards of design principles, you can implement basically any sort of exception system by a set of context switches; certainly good design is just but one goal and this approach might be overlooking the performance and conformance constraints in ways i don't completely understand. 

Regarding something more concrete, here is a scenario for you to consider in your architectural design: suppose a user wants to serialise an execution context to disk (meaning that objects in the stack frame need to be serialised individually). In this case, it would pay that you have a generic way to visit the stack frames and invoke some operations other than cleanup.

hope this helps,
Charles


> 
> That said, lowering IR from a "conventional" style —
> where cleanups appear as normal code and control
> dependencies are expressed directly with normal-ish control
> flow — to the form required by an SEH-like implementation
> would indeed require operations not fundamentally dissimilar
> from coroutine extraction.
>