On Sun, 26 Aug 2001, David Stephenson wrote:
> 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?
1. Is there any flag that mark the essential difference of the
"real" entry and the "fake" & "dangling" entry? I noticed the real entry
and exit are represented by green blocks. It seems that it is green
because it is not in_out_same.
2. Is there any special reason to left the "dangling" entry there?
3. Another question is about the SWITCH casegotos. In the whirl tree for
Programs containing switch structure, why not make the BLOCKs for each
"case" the children of the CASES? In pro64, casegotos are used and the
BLOCKS for the cases are NOT in the subtree rooted from the SWITCH wn.
4. I know that Pro64 introduces the concept of region to divide a very big
function into different parts to deal with them separately. What is the
guide to split the function into regions? Does Pro64 generates regions
into which there are several entry from the original function
(e.g. GOTOs)?
>
> 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
>
>
--
Regards
Peng
--
Peng Zhao pengzhao@xxxxxxxxxxxxxx
http://www.cs.ualberta.ca/~pengzhao
TEL (Lab): (780)492-3725 Lab: CSC251
|