[LLVMdev] RFC: Exception Handling Proposal II

[Bill Wendling]

On Nov 24, 2010, at 11:49 PM, John McCall wrote:

> On Nov 24, 2010, at 9:01 PM, Bill Wendling wrote:
>> On Nov 24, 2010, at 6:41 PM, John McCall wrote:
>>>> We know from experience that once this information is lost, it's *really* hard to get it back again. That's what DwarfEHPrepare.cpp is all about, and I want to get rid of that pass because it's a series of hacks to get around our poor EH support.
>>> 
>>> While I agree that the hacks need to go, there is always going to be some amount of custom codegen for EH just to get the special data to flow properly from landing pads to the eh.exception intrinsic and the dispatch instruction.  My design would give you some very powerful assumptions to work with to implement that:  both the intrinsic calls and the dispatch would always be dominated by the region's landing pad, which would in turn only be reachable via specific edges.  I don't know how you're planning on implementing this without those assumptions, but if you say you don't need them, that certainly diminishes the appeal of my proposal.
>> 
>> We actually have the "reachable via specific edges" check in our code right now. But when we tried to allow exceptions to be marked as proper "cleanups", the assumption was violated. So I'm wary of making this same assumption twice.
>> 
>> But anyway, I think that I can gather the necessary information from the region numbers and the invokes' "unwind to" edges to create the EH tables. The only intrinsic call that should remain is the one that gets the EH pointer. And that's only needed by the catch blocks.
> 
> Right, I agree that it's easy to assemble the EH tables for a given invoke under any of these variants.  We don't need any new constraints to make this easier.
> 
> What I'm talking about is the flow of data from the start of the landing pad to two points:
> 1.  The (optional) call to @llvm.eh.exception.
> 2.  The dispatch instruction.
> Specifically, in DWARF EH, the personality function writes these two values into the frame somewhere — maybe into registers, maybe into the EH buffer, whatever — and that information needs to flow to the appropriate intrinsic/instruction.  You can't just stash it aside, because the cleanup might throw and catch an exception between points A and B.  I'm really not sure how this is supposed to work if there's no guaranteed relationship between the landing pad and the intrinsic/dispatch (†).  The most sensible constraint — dominance — is equivalent to saying that each region has at most one landing pad.


I did a sample test with gcc and it is stashing the information off to the side.

#include <cstdio>

void foo();
void qux();

struct A {
  ~A() { try { throw 0; } catch (double) { printf("hoo\n"); } }
};

void bar() {
  try {
    A a;
    foo();
  } catch (const char *c) {
    printf("hello world! %s\n", c);
  }
}

The cleanup part for the "foo" call has this:

L24:
        # basic block 4
L3:
        movl    %edx, %ebx
        movq    %rax, %r13
        movl    $4, %edi
        call    ___cxa_allocate_exception
        movq    %rax, %rdi
        movl    $0, (%rax)
        movq    __ZTIi at GOTPCREL(%rip), %rsi
        xorl    %edx, %edx
LEHB2:
        call    ___cxa_throw
LEHE2:

edx and rax hold the EH selector value and EH object pointer respectively. They get restored before continuing on to the catch in bar (if they get there, which I don't think they will in this case).

But that's beside the point. I see what you mean. There is an impedance mismatch going on here. :-) Your use of dominance as a constraint was confusing me. I characterize it as losing information, but it results in the same problem. I.e., after a throw and catch in a cleanup, we need to be able to reconstruct the original EH value and object pointer, but cannot determine that if we are simply branching to yet another block from that catch. Using the dispatch instruction gives us this information.

The proposal can be easily modified to the "landing pad dominates the dispatch" view of the world. And if we're careful, we can keep the guarantee that only unwind and dispatch edges may jump to a landing pad throughout the optimizer. :-)

Thanks for shedding light on this!

-bw