[LLVMdev] unwinds to in the CFG

[Gordon Henriksen]

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.

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

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.

>>> B. redefine the dominator tree by modifying the GraphTraits
>>> i.  A dom B means that all instructions in A are guaranteed to  
>>> execute before any instructions in B.
>>> ii. the domtree may have multiple roots.
>>>
>>> Multiple roots occurs when the entry block 'unwinds to' another  
>>> block.
>>
>> It seems highly problematical that static allocas might not  
>> dominate their uses.
>
> I'm not sure what you mean by that. It would be invalid to "alloca"  
> in a BB then use the pointer in the unwind dest. You can't escape  
> that.

I'm just giving an example of something that breaks if the entry-block- 
dominates-all-blocks property is violated. Front-ends and  
transformations rely upon this property by unconditionally placing  
their 'local variable declaration' allocas in the entry block.

— Gordon