[LLVMdev] unwinds to in the CFG

[Nick Lewycky]

Gordon Henriksen wrote:
> On 2008-03-29, at 00:57, Nick Lewycky wrote:
> 
>> Gordon Henriksen wrote:
>>
>>> What blocks would a phi node in %catch require for a case like this?
>>>
>>>    define i8 @f(i1 %b) {
>>>    entry:
>>>      b label %try
>>>    try: unwinds to %catch
>>>      b i1 %b, label %then, label %else
>>>    then: unwinds to %catch
>>>      ret void
>>>    else: unwinds to %catch
>>>      ret void
>>>    catch:  ; What are my predecessors?
>>>      ret void
>>>    }
>> 'catch' has 3 preds, %try, %then and %else.
> 
> Would it be more natural to claim %entry and %try as the predecessors?  
> This is similar to how a high level language disallows variable  
> declarations from a try block to be visible from the catch.

In LLVM the rule is that an instruction must be dominated by its 
operands. Predecessors and successors don't enter into it, except to 
define the dominance tree.

> object x;
> try { x = null; }
> catch { use(x); } // error, x is uninitialized
> 

Yes, I know. I'm planning to accomplish this by defining pred/succ 
sensibly such that we get a domtree where the equivalent LLVM code would 
be invalid.

> Also, consider a phi node:
> 
> phi i32 [%x, %bb1] ; %x defined in %bb1.
> 
> Depending on what type of predecessor %bb1 is, some of the models  
> you've mentioned declare this phi node illegal.

Oh. Now that's a very good point.

bb1: unwinds to %cleanup
   %x = add i32 @foo, @bar
   ret i32 %x
cleanup:
   %y = phi i32 [%x, bb1]

If %cleanup has %bb1 as a predecessor then the above is legal. (PHI 
nodes being the only Instruction that works on pred/succ and not 
dominators.)

And you're right, the fix for that it to make the predecessor be bb1's 
preds (if it has any). This is nastier than I was expecting...

Nick