[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR

[Reid Kleckner]

On Tue, Nov 18, 2014 at 5:52 PM, Kaylor, Andrew <andrew.kaylor at intel.com>
wrote:

>  > For DWARF EH and SjLj, the backend is responsible for handling most of
> the EH work. It seems like it would be a more consistent design for SEH to
> do the same.
>
>
>
> Looking beyond SEH to C++ exception handling for a moment, it seems to me
> that clang may be handling more than it should there.  For instance, calls
> like “__cxa_allocate_exception” and “__cxa_throw_exception” are baked into
> the clang IR output, which seems to assume that the backend is going to be
> using libc++abi for its implementation.  Yet it has enough awareness that
> this won’t always be true that it coughs up an ErrorUnsupported failure for
> “isWindowsMSVCEnvironment” targets when asked to emit code for “try” or
> “throw”.
>
>
>
> Should this be generalized with intrinsics?
>

We should just teach Clang to emit calls to the appropriate runtime
functions. This isn't needed for SEH because you don't "throw", you just
crash.


> Also, I’m starting to dig into the outlining implementation and there are
> some things there that worry me.  I haven’t compared any existing code that
> might be doing similar things, so maybe these issues will become clear as I
> get further into it, but it seemed worth bringing it up now to smooth the
> progress.  I’m trying to put together a general algorithm that starts at
> the landing pad instruction and groups the subsequent instructions as
> cleanup code or parts of catch handlers.  This is easy enough to do as a
> human reading the code, but the way that I’m doing so seems to rely fairly
> heavily on the names of symbols and labels.
>

Look at lib/Transforms/Utils/CloneFunction.cpp. Most of that code should be
factored appropriately and reused. It uses a ValueMapping that we should be
able to apply to the landing pad instruction to map the ehselector.slot to
a constant, and propagating that through.


> For instance, following the landingpad instruction I expect to find an
> extract and store of “exn.slot” and “ehselector.slot” then everything
> between that and wherever the catch dispatch begins must be (I think)
> cleanup code.  The catch handlers I’m identifying as a sequence that starts
> with a load of “exn.slot” and a call to __cxa_begin_catch and continues
> until it reaches a call to __cxa_end_catch.
>

I think we'll have to intrinsic-ify __cxa_end_catch when targeting
*-windows-msvc to get this right. If we don't, exception rethrows will
probably not work. We don't really need an equivalent of __cxa_begin_catch
because there's no thread-local EH state to update, it's already managed by
the caller of the catch handler.


> The calls to begin/end catch are pretty convenient bookends, but
> identifying the catch dispatch code and pairing catch handlers with the
> clauses they represent seems to depend on recognizing the pattern of
> loading the ehselector, getting a typeid then comparing and branching.  I
> suppose that will work, but it feels a bit brittle.  Then there’s the
> cleanup code, which I’m not yet convinced has a consistent location
> relative to the catch dispatching and I fear may be moved around by various
> optimizations before the outlining and will potentially be partially shared
> with cleanup for other landing pads.
>

We either have to pattern match the selector == typeid pattern in the EH
preparation pass, or come up with a new representation. I'm hesitant to add
a new EH representation that only MSVC compatible EH uses, because it will
probably trip up existing optimizations. I was hoping that something like
the pruning logic in "llvm::CloneAndPruneFunctionInto" would allow us to
prune the selector comparison branches reliably.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141118/ec8e42c8/attachment.html>