pro64-support
[Top] [All Lists]

Re: multi-entry CFG

To: Peng Zhao <pengzhao@xxxxxxxxxxxxxx>
Subject: Re: multi-entry CFG
From: David Stephenson <dlstephe@xxxxxxx>
Date: Sun, 26 Aug 2001 20:51:33 -0700
Cc: sgi <pro64-support@xxxxxxxxxxx>
Organization: SGI -- Compilers
References: <Pine.LNX.4.21.0108261716001.26972-201000@peers.cs.ualberta.ca>
Sender: owner-pro64-support@xxxxxxxxxxx
Peng Zhao wrote:

>         Enclosed two files are a simple C program and the related CFG
> created in the pre_optimizer. There are several entries for the CFG. And
> I want to use cfg->Entry_bb()->Id() & cfg->Exit_bb()->Id() to get the
> entry&exit of the CFG(Initially, I had thought there should be only one
> entry and one exit). The result is:
> 
> entry=16,exit=17
> 
>         Can somebody explain me when this kind of CFG is generated?

In the WOPT CFG, blocks 9 and 10 are leftovers.  Consider the inner
branch statement:

        if (i == (length -2)) {
          goto L1;
        } else {
          printf(" i == (length -1) %d\n", i);    
          goto L2;
        }

If there were no goto statements, then WOPT would have generated a
CFG like:
              |
              6
             / \
            7   8
             \ /
              9
              |

Instead, the gotos cause blocks 7 and 8 to branch to blocks 11 and 12
which contain the labels L1 and L2, respectively.  Block 9 is still
generated, but is left dangling with no predecessors.  DCE will later
eliminate it.

Now, in order to keep all of the dominance relations well defined,
a new "fake entry" block 16 is introduced.  This happens whenever
the CFG contains more than one block with no predecessors.  The
successors of the "fake entry" block are all blocks with no
predecessors: 1, 9, and 10.  Similarly a "fake exit" block is
introduced with predecessors 15, 9, and 10.  (One subtlety:
although 1 is a successor of 16, 16 is not a predecessor of 1.
Fake entries and exits use "one-sided" edges to connect.)

The postscript graph you are looking at is from optimizer feedback,
and it looks a little different from the CFG graph.  In particular,
the "one-sided edges" from 16 to 1,9,10 and from 15,9,10 are not
all shown.

                                                        - David

-- 
David Stephenson        http://reality.sgi.com/dlstephe_engr/

<Prev in Thread] Current Thread [Next in Thread>