[LLVMdev] CFG entry and exit blocks

John Criswell criswell at uiuc.edu
Tue Mar 30 19:51:52 PDT 2010


Dear Trevor,

I'm too lazy to convert your .dot file into a graph file, but I'll make 
some comments anyway.
:)

First, LLVM does not guarantee that a function has a single exit block.  
Multiple basic blocks can have a return instruction as their terminator 
instruction.  There is a pass (Unify Function Exit nodes i.e., 
-mergereturn <http://llvm.org/docs/Passes.html#mergereturn>) that 
transform a function to have only 1 return instruction.

Now, I haven't looked at LLVM's new exception handling facilities 
recently, but there used to be an unwind instruction that would unwind 
the stack to the nearest dynamically executed invoke instruction (see 
the LLVM Langauge Reference Manual for more details).  Functions that 
use unwind would naturally have multiple exits.  I don't know of a 
transform that would change it to have a single exit (or one return and 
one unwind).

-- John T.

Trevor Harmon wrote:
> Hi,
>
> I'm confused about the entry and exit blocks of an LLVM CFG. I  
> understand that every CFG has one and only one entry block, and this  
> is confirmed by the existence of the getEntryBlock function in the  
> Function class.
>
> But what about exit (a.k.a. return) blocks? At first I assumed that  
> LLVM CFGs have one and only one exit block, too, but the following  
> code is a counter-example:
>
> int simple(int j) {
>      try {
>          if (j > 50) throw 100;
>      } catch (int status) {
>          j++;
>      }
>
>      return j;
> }
>
> This produces the CFG shown in the attachment, which appears to have 3  
> exit blocks. At least, there are 3 blocks with no successors. (I don't  
> yet understand the semantics of the "invcont" and "Unwind" blocks, so  
> perhaps I'm misunderstanding something here.)
>
> Anyway, given this code, how would one identify the "real" exit block  
> (the one labeled "return")? Obviously I can't just search for the  
> block without successors because there are 3 of them.
>
> Thanks,
>
> Trevor
>
>   




More information about the llvm-dev mailing list