llvm dev - May 2009 - [LLVMdev] Nested exception handlers

Now that I've got exceptions working, I'm kind of wondering how to 
handle the case of nested "try" blocks. Say I have some code that
looks
like this:

  try {
    try {
      if (test) {
        // throw something
      } else {
        return;
      }
    } catch e:Except1 {
    } catch e:Except2 {
    } finally {
    }

    // more code...
  } catch e:Except3 {
  } finally {
  }

Turning this into a list of basic blocks is starting to get rather 
complex. In particular:

    * For the innermost try block, there will be 4 possible selectors,
      corresponding to Except1, Except2, Except3 and "other".
          o The first two selectors jump directly to the catch blocks
            for their respective exceptions.
          o The third selector needs to execute the inner 'finally'
            block first.
          o The fourth selector (0 which is a cleanup handler) needs to
            execute both finally blocks and then re-throw the exception.
    * The return statement also needs to execute both finally blocks and
      then return.
    * Then in the outer try block, there will be another exception
      selector with two entries, Except3 and "other" (0).
    * The "fall through" for the outer try block also needs to execute
      the outer finally block.

In addition, the exception object for Except3 can come from two 
different llvm.eh.selector instructions, which means that it either 
needs to be a phi node or it needs to be a memory variable.

I'm wondering if anyone has dealt with this sort of thing and has or  
has advice on how to approach the problem. It seems like I almost need 
to have my higher-level CFG include a "Local JSR" and "Local
Return"
operator which is lowered into code that sets a state variable and then 
does a switch at the end of the finally block to determine where to jump 
back to.

-- Talin

Hi Talin,
> Now that I've got exceptions working, I'm kind of wondering how to 
> handle the case of nested "try" blocks. Say I have some code that
looks
> like this:
take a look at what llvm-gcc does for this kind of thing.

Ciao,

Duncan.

Since llvm-gcc is a rather large code base, which I have never looked at 
(or even run), could you give me a starting point of where to look?

One thing I'd be interested in knowing is whether the 
llvm.eh.exception() intrinsic can be called more than once in a landing pad.

Say for example I have a nested try block, so that there are two landing 
pads, one for the inner try block, and one for the outer. Let's say that 
the inner landing pad has a "finally" block - a cleanup handler. This 
means that the inner try block must catch every exception type so that 
it can execute the cleanup even if there was no specific catch handler 
for that exception type.

At the end of the finally block, we need to jump to various different 
destinations depending on how the finally block was entered - return, 
fall through, throw, etc. In the case where we failed to catch an 
exception in the inner try block, but the outer try block has a catch 
handler for that exception, the finally block needs to jump to the outer 
landing pad. There are three ways this could happen:

1) Call _Unwind_Resume, using an "invoke" IR instruction whose unwind 
block points to the outer landing pad. This seems like it would be 
expensive however.

2) Branch directly to the start of the outer landing pad, and restart 
the exception dispatch all over. The problem with this is that the outer 
landing pad calls llvm.eh.exception() and llvm.eh.selector(), and I 
don't know if it's valid to call them at this point. Normally you
don't
jump to a landing pad directly, you get there via the personality 
function forcing a jump to that label. I don't know whether it is legal 
for the inner landing pad to jump to the start of the outer landing pad.

3) Branch directly to the individual catch blocks in the outer landing 
pad. In order to know which catch block to branch to, we need to add 
additional selectors to the inner landing pad representing the possible 
catch blocks in the outer landing pad that might catch the inner exception.

The problem with this scheme is that now the liveness of the current 
exception object is all tangled up.  The jump from the inner landing pad 
to the outer catch block passes through one or more cleanup blocks, each 
of which ends with a conditional jump. Each cleanup block has multiple 
predecessors, each predecessor setting a state variable telling the 
cleanup block where to jump to after finishing the cleanup. For a given 
cleanup block, "return" might set state = 0, "fall through"
= 1, "catch
block 1" = 2, "catch block 2" = 3 and so on. Notice that for some
of
those states (2, 3), there is a current active exception object, and for 
some (0, 1) there is not. That means that the value of the exception 
object is undefined for some predecessor blocks, so a regular phi node, 
won't work, and even storing the exception pointer in a local variable 
won't work because the compiler will notice that there are some code 
paths where the exception variable never gets set. Now, I happen to know 
that the code will never jump to a catch handler when there is no active 
throwable, but I am not sure that the compiler knows this.

Duncan Sands wrote:
> Hi Talin,
>
>   
>> Now that I've got exceptions working, I'm kind of wondering how
to
>> handle the case of nested "try" blocks. Say I have some code
that looks
>> like this:
>>     
>
> take a look at what llvm-gcc does for this kind of thing.
>
> Ciao,
>
> Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>