|IR Representation firstname.lastname@example.org (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-04)|
|Re: IR Representation email@example.com (2015-09-05)|
|Re: IR Representation firstname.lastname@example.org (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-07)|
|Re: IR Representation email@example.com (2015-09-08)|
|Re: IR Representation firstname.lastname@example.org (George Neuner) (2015-09-08)|
|Re: IR Representation email@example.com (=?UTF-8?B?Q8Opc2Fy?=) (2015-09-11)|
|Re: IR Representation DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2015-09-12)|
|From:||Hans-Peter Diettrich <DrDiettrich1@netscape.net>|
|Date:||Sat, 12 Sep 2015 19:45:09 +0200|
|References:||15-09-005 15-09-006 15-09-010 15-09-011 15-09-013|
|Posted-Date:||12 Sep 2015 15:43:08 EDT|
> Now I am wondering, how do you usually represent conditional nodes and
> looping structures using trees?
> c = a + b;
> if c > 10 goto L1 else goto L2
> L1: a = 10;
> goto L3;
> L2: a = 20;
The general representation of control flow forms *graphs*, not *trees*.
In your example control flow branches off in the "if" statement, into
two branches starting at L1 and L2 respectively, which happen to join
again at L3. You can consider each GOTO as a leaf in a tree, so that you
can convert the graph into trees. Then, in the case of well structured
code, L1 and L2 become child nodes of the "if" statement, and L3 will
become its sequential successor (right sibling), as L3 is the common
target reachable by both branches. The compiler can eliminate a GOTO
leaf and replace it by the tree of the GOTO target label, which then
indicates the next instruction during sequential execution. This process
continues until all trees have been merged into one big tree.
Return to the
Search the comp.compilers archives again.