Static Slicing in the Presence of GOTO Statements. IBM T. J. Watson Research Center. P. O. Box 704. Yorktown Heights, NY

Transcription

1 Static Slicing in the Presence of GOTO Statements Jong-Deok Choi Jeanne Ferrante* IBM T. J. Watson Research Center P. O. Box 704 Yorktown Heights, NY Abstract A static program slice is an extract of a program which can help our understanding of the behavior of the program; it has been proposed for use in debugging, optimization, parallelization, and integration of programs. This paper considers two types of static slices: executable and non-executable. Ecient and well-founded methods have been developed to construct executable slices for programs without goto statements; it would be tempting to assume these methods would apply as well in programs with arbitrary goto statements. In this paper, we show why previous methods do not work in this more general setting, and describe our solutions that correctly and eciently compute executable slices for programs even with arbitrary goto statements. Our conclusion is that goto statements can be accommodated in generating executable static slices. Categories and Subject Descriptors: D.2.5 [Software Engineering]: Testing and Debugging {Debugging aids, D.2.6 [Software Engineering]: Programming Environments General Terms: Algorithms, Languages Additional Key Words and Phrases: Program analysis, slicing, debugging, testing address:fjdchoi,ferrantg@watson.ibm.com 1

2 1 Introduction Slicing is a technique to extract statements of a program that inuence the value of a variable at a particular point of the program. Program slicing, originally proposed by Weiser [17], can help a programmer understand a program. It can also be used for program debugging [14, 17], for automatic parallelization and/or optimization of programs [17], and for program integration [9, 10]. A static program slice, according to Weiser, is an executable portion of the original program whose behavior on the given variable at the given program point is indistinguishable from that of the original program. For certain purposes, such as program debugging, it is essential to have an executable notion of slice. A static slice is independent of the input to the program and is, therefore, dierent from a dynamic slice [11, 2, 4], which depends on the input. This paper is concerned with executable static slices. Denition 1.1 An executable slice of a program with respect to program point p and variable x consists of a subset of the program that computes the same sequence of values for x at p [17]. In [14], Ottenstein and Ottenstein dened a program slice to be simply the set of statements that inuence the value of the variable; they suggested the Program Dependence Graph (PDG) [6] as the natural basis for computing this notion of non-executable slice. For many applications, such as optimization and program understanding, only this weaker notion of slice is needed. Denition 1.2 A slice of a program with respect to program point p and variable x consists of a set of statements of the program that might aect the value of x at p [10]. Note that an executable slice by Denition 1.1 is also a slice by denition 1.2. Reps and Yang [15] proved that slicing guided by the PDG indeed yields correct executable slices, using a language model without arbitrary goto statements. One might be led to conjecture, then, that the PDG could be used to construct executable slices even in the 2

3 presence of arbitrary goto statements. In this paper, we show that the classical PDG, de- ned in [6], is not adequate for constructing executable slices. We then give two methods for computing executable slices. The rst method is easier to compute than the second, but yields in general a larger slice. We can conclude that while programs with goto statements do require extra eort for executable slices, the problems are also easily overcome. In [3], Ball and Horwitz independently developed a slicing algorithm for programs with arbitrary control ow using the same technique as our rst method, which is based on augmenting the CFG. They also provide a correctness proof of the method based on semanticspreserving transformations. Their proof uses execution traces of the program to relate the behavior of the original CFG to the sliced CFG, as does ours. Lyle's algorithm [13] extends Weiser's algorithm to handle goto statements, but is more conservative than our rst method. Gallagher's algorithm [7] improves Lyle's algorithm and computes slices similar to those from our rst method. Recently, Agrawal developed a method to compute the same slice as our rst method using a lexical successor tree instead of an augmented CFG [1]. It is claimed this is an ecient method for programs with only structured goto statements such as continue and break. Since Agrawal's method computes the same slices as our rst method, it also yields in general a larger slice than our second method. 2 Background To prove the correctness of our slicing algorithms, we use a simple model language whose abstract syntax is provided in Figure 1. Each statement S has a set of unique labels. We have left the syntax of expressions (E) unspecied. We assume expressions consist of operations, including assignment operations, over (variable) identiers. Such variables can include both scalars and arrays. An expression can be viewed as a function mapping from a program state to another program state, where program state,, is a set of variables and their values at given point of execution. We use 0 to denote the initial program state. Execution control ows from a statement S i to the statement that lexically follows S i, 3

4 P ::= begin S; EXIT end S ::= LSET:E LSET:goto <target> LSET:if (E) goto <target> S1; S2 null EXIT ::= LSET: exit LSET ::= L L, LSET <target> ::= L Figure 1: Abstract Syntax of the Model Language except for the conditional and unconditional goto statements. The null statement does not aect the program behavior and is included for the convenience of the discussion. The model language does not include loops, which can be modeled by conditional and unconditional goto statements Execution Behavior of a Program During an execution of a program, each statement can have multiple execution instances, each of which we call an execution event. Execution events (henceforth called events) are ordered by their subscripts: event e i immediately follows event e i?1 and, in turn, is immediately followed by event e i+1. The execution behavior of each event can be dened in terms of the change in the program state due to that event. Let i?1 be the program state immediately after the event e i?1, and i the program state immediately after the event e i. Then, the execution behavior of event e i can be represented by a (state) transition i that captures the dierence between i?1 and i. 1 Other branching statements such as continue and break can be handled using the goto statements. 4

5 We dene Stmt(e i ) to be the statement of which e i is an execution instance. We also dene Stmt( i ) to be the same as Stmt(e i ). With these, we can dene the run-time trace of a program written in the model language as follows: Denition 2.1 The statement trace of the i 0 th event, e i, is a tuple < S j ; i >, where S j = Stmt( i ). The program trace (or simply trace) of program P with initial state 0, written as T race(p; 0 ), is the string consisting of all statement traces generated in order during execution. 2.2 Program Representation The PDG is a well-accepted program representation for various program analyses, including slicing. The PDG of a program consists of two subgraphs: the data dependence graph (DDG) [12] and the control dependence graph (CDG) [6]. Three well-known data dependences are as follows: true or ow dependences representing a write access of a variable followed by a read access of the same variable (without any intervening write accesses of the same variable); output dependences representing a write access to a variable followed by another write access to the same variable; and anti-dependences representing a read access to a variable followed by a write access to the same variable. Among the three, only ow dependences aect slicing. Therefore, we will consider only ow dependences in this paper. The CDG is built from the CFG of the program, which is dened as follows: Denition 2.2 A control ow graph (CFG) of a program P is a directed graph CF G =< N CF G ; E CF G ; Entry > : The nodes N CF G represent the statements of P, one node for each statement of P, a single exit node Exit, and an additional Entry node. The edges E CF G represent transfer of control between the nodes. We assume there is an edge to statement node exit from any node that can exit the program. 5

6 1: entry 2: if (Q) goto 5 3: x = 4 CFG ENTRY PDG ENTRY 4: goto : x = 5 6: y = x : exit : go to stmts : CDG edge : DDG edge Figure 2: Example CFG and PDG Nodes for conditional statements (i.e., if statements) have two outgoing edges, each of which is by convention labeled with either true or false. 2 Nodes for non-conditional statements have one outgoing edge, which is not labeled. Our algorithms do not rely upon edge labels, and for simplicity we do not show them in our examples. Denition 2.3 A node n is post-dominated by a node ^n in CFG if every directed path from n to exit contains ^n. Let IP DOM(n), the immediate post-dominator of n, be the closest post-dominator node of n on any path from n to exit in CFG. The relationship of IP DOM can be represented as a tree, P OST DOM. Denition 2.4 [6] For two nodes n and m in CF G, m is control dependent on n i 1. there exists a path P from n to m with any node ^n (excluding n and m) on P postdominated by m and 2. n is not post-dominated by m. 2 This restriction to at most two outgoing edges is only for the simplicity of the discussion. The techniques in this paper are applicable to CFGs with arbitrary number of outgoing edges. 6

7 If m is control dependent on n then n must have two outgoing edges. Following one of the edges always leads to m, and using the other edge there is a path to exit that bypasses m. Figure 2 shows an example program, its CFG, and its PDG. The nodes of PDG are the same as CFG. The edges are given by the control dependence and the data dependence relation between these nodes. Note that S 2 is a single statement. In what follows we use! c to denote a control dependence edge,! f to denote a ow dependence edge, and! cf g to denote a control ow edge. We also use! x to denote transitive closure of edges, where x can be c, f, or cfg. We state the following lemma, whose proof appears in [16]: Lemma 2.5 For two nodes n and m in CF G, m is transitively control dependent on n, i.e., n! c m, i 1. there exists a path P 1 from n to m, and 2. there exists a path P 2 from n to exit that bypasses m, and 3. any node strictly between n and m in P 1 does not occur in P 2. 3 Problems with Constructing Executable Slices In this section, we rst describe a well-known slicing technique using PDG's for computing slices of goto-less programs. We then show how the technique fails to correctly compute executable slices when applied to a program with goto statements. Denition 3.1 For a node s of a program dependence graph P DG, the slice of P DG with respect to s, written as SL(P DG; s), is the set of nodes in P DG that can reach s via a path of ow or control dependence edges [9]. With a PDG, slicing of a variable at a particular statement, S i, involves identifying nodes that reach S i by control dependence or data dependence edges. This construction can be done in linear time in the size of the slice. We often illustrate the slice obtained from a 7

8 1: entry ENTRY 2: if (Q) goto 5 3: x = : x = 5 6: y = x 7: exit 5 6 Figure 3: Example (Incorrect) Slicing P DG by showing the subgraph of the P DG which consists of the nodes in the slice and the relevant ow and data dependence edges. For the PDG shown in Figure 2, Figure 3 shows the slice of P DG with respect to node S 6, SL(P DG; S 6 ), as well as the subgraph of P DG corresponding to the slice. Note that the value of x at S 6 is 5 whenever SL(P DG; S 6 ) is executed regardless of the value of `Q'. However, in the original program, the value of y at S 6 is 4 when Q is false; the slice is not a correct executable slice of the program with respect to S 6. This example shows that the classical PDG is not an adequate representation for constructing executable slices by the method described in Denition 3.1. Prior control-ow-based methods [17] also produce incorrect slices for this example and in general are inadequate for handling un-conditional branch statements such as goto; goto statements do not include any relevant variables [17] and so can be incorrectly excluded by such methods, resulting in incorrect control ow in the slice. In the following sections, we present two methods to solve this problem. The rst method is to build an augmented program dependence graph (AP DG) that can be used, instead of the PDG of the program, for correct slicing. The APDG, like the PDG, consists of two sub-graphs: the data dependence graph, which is the same as used in the PDG; and the augmented control dependence graph (ACDG), which is dierent from the classical CDG used in the PDG. The ACDG can be built by augmenting the CFG and applying the usual CDG construction algorithm [6, 5] to the augmented CFG (ACF G). We call the slice from 8

9 the APDG the augmented slice, written as SL(AP DG; s), and show it is a correct executable slice. The second method uses the same classical PDG but a dierent slicing technique from the one in Denition 3.1. We also give an example which illustrates the dierence between the two methods. 4 Correct Slicing (Method 1) In this section, we rst provide a denition of a correct executable slice of a program. We then dene ACDG and APDG, and show slicing over the APDG, instead of the PDG, yields a correct executable slice. Denition 4.1 [correct-executable-slice] Let P slice be an executable slice of a program P org, S be the set of statements in P slice, and P roj S (P org ; 0 ) be the projection of T race(p org ; 0 ) that contains only those statement traces produced by statements in S. P slice is a correct executable slice of P org if P roj S (P org ; 0 ) is identical to T race(p slice ; 0 ). Informally, P slice is a correct executable slice of P org if P slice and P org generate the same trace for each statement in P slice. The slice in Figure 3 and the original program in Figure 2 do not generate identical traces for the statements in the slice; the slice is an incorrect executable slice. On the other hand, the augmented slice in Figure 4 (computed from the APDG in Figure 5) and the original program generate identical traces for the statements in the augmented slice; the augmented slice is a correct executable slice. To dene the augmented CDG (ACDG) and the augmented PDG (APDG) formally, we rst dene a fall-through statement as follows: Denition 4.2 The fall-through statement of a statement S i in program P is the statement that lexically follows S i. Informally, the fall-through statement of S i is the statement to which the program control ow coming into S i would be forwarded if S i is replaced with null statement. For example, 9

10 1: entry 2: if (Q) goto 5 ENTRY 3: x = 4 4: goto 6 5: x = 5 6: y = x 7: exit Figure 4: (Correct) Augmented Slicing the fall-through statement of S 4 in Figure 2 is S 5. 3 Denition 4.3 The augmented control ow graph of CF G =< N CF G ; E CF G ; Entry > is a directed graph ACF G =< N CF G ; E ACF G ; Entry >; where E ACF G = E CF G [ E F T, where E F T statement to its fall-through statement. is the set of fall-through edges, one from each goto Slicing involves deleting statements, which may aect the control ow of the program. A fall-through edge in ACF G captures the necessary control ow if the corresponding goto statement is deleted from the program. Denition 4.4 The augmented CDG of a program, ACDG, is the CDG computed using ACF G, the augmented CFG of the program. Figure 5 shows the ACFG and APDG of the example program in Figure 2. additional edge in ACFG and APDG. Note the 3 For a language with structured conditionals such as if : : : else : : : endif, the fall-through statement of an if statement is the statement that lexically follows the corresponding endif statement. The fallthrough statement of the statement that lexically precedes else is also the statement that lexically follows the corresponding endif statement. 10

11 ACFG APDG ENTRY ENTRY : fall through edge : CDG edge due to fall through edge Figure 5: Augmented CFG and Its APDG Denition 4.5 The augmented slice ( a-slice ) of a program P with respect to s, SL(AP DG; s), is the slice over the augmented PDG of P. The sliced program of P, P slice, is constructed from SL(AP DG; s) as follows: 1. It consists of statements of P represented in SL(AP DG; s) plus the exit statement. 2. The label of a statement S i 62 SL(AP DG; s) is added to the label set of S j 2 SL(AP DG; s), where S j is the closest postdominator of S i that is in SL(AP DG; s). We provide in Appendix a proof that an augmented slice yields a correct executable slice. Note that the cost of computing an a-slice is proportional to the size of the a-slice. In computing an a-slice of a program, the only modications applied to the original program are the association of additional labels with statements, and the deletion of statements. The former is an insignicant change, compared to adding new program statements, and the latter is a desirable characteristic for program integration [9]. However, the APDG of a program, from which a-slices are computed, is in general larger than the PDG of the same program, 11

12 ACFG APDG L1: x = 10; L1 L0 L1 L2: if ((a+b+c) > (d+e+f)) L3: goto L4; L2 L2 else L4: y = x; L3 L4 L3 L4 L5:... L5 L5 : go to stmts : fall through edge :CDG edge :DDG edge Figure 6: Example Code Segment and Its Augmented CFG and computing slices from APDG requires more time and space than computing them from the PDG. Furthermore, an a-slice can have \spurious" statements in it, as illustrated by the example code segment in Figure 6. To make the example more general, we have written it in C, rather than in the model language in Figure 1. Note that, as described in Section 4, the fall-through statement of L3 is L5. In the gure, L0 is the CFG node on which L1, L2, and L5 are all control dependent. Also, L2 is shown with data dependence edges, each of which corresponds to a variable read-accessed at L2. In the example, (the statement of) L4 is not control dependent on either L2 or L3, since L4 postdominates L2 and L3. However, the fall-through statement of L3 is L5, and L4 is augmented control-dependent on L3, which in turn is control dependent on L2. The a-slice of L4 not only includes L3 and L2, but SL(AP DG; L2), the slice of L2 (not shown). Since there are six variables read-accessed in S2, the size of SL(AP DG; L2) can be large, although none of the values read-accessed by L2 aects L4. This example shows that an a-slice of a program can include statements that do not aect the statement for which the slice is computed. The correct slice of the example could simply be the program consisting of L1 followed by L4. In the next section, we describe an algorithm that computes this smaller 12

13 slice as the executable slice for the example code segment. 5 Correct Slicing (Method 2) As stated in the previous section, the method presented in this section generally computes a smaller slice than the rst method, at the expense of additional goto statements. To carry out this second method, we generalize the denition of correct executable slice to include these additional statements, as well as introduce a new kind of slice, a CFG slice, given in Denition 5.2. The executable slice of the example code segment - L1 followed by L4 - is obtained by rst applying the algorithm in Figure 7, then applying a simple optimization: removing redundant cascaded goto statements. For some applications, additional goto statements in the slice is acceptable. For example, in debugging, the debugger can hide such goto statements when displaying slices to the user. Since P slice now can have additional goto statements in it, we generalize the denition of correct executable slices as follows: Denition 5.1 [correct-executable-slice (2)] Let P slice be an executable slice of a program P org ; S be the set of statements in both P slice and P org, i.e. S = fs j s 2 P slice \ P org g; P roj S (P org ; 0 ) be projection of T race(p org ; 0 ) onto S, which contains only the trace of statements in S; and P roj S (P slice ; 0 ) be projection of T race(p slice ; 0 ) onto S, i.e., T race(p slice ; 0 ) minus traces of the additional goto statements. Then P slice is a correct executable slice of P org if P roj S (P org ; 0 ) is identical to P roj S (P slice ; 0 ). The dierence between Denition 4.1 and Denition 5.1 is that S is the set of statements in P slice in the former, but is the set of statements in both P slice and P org in the latter; S in the latter, thereby, excludes the additional goto statements not originated from P org. Note that since P slice is a subset of P org in the rst method, slices from the rst method also satisfy Denition 5.1. This denition, as well as Denition 4.1, contains stronger conditions than 13

14 Denition 1.1 since the latter concerns the execution behavior in terms of only the variable for which the slice is taken. We now dene the notion of CFG slice. A CFG slice with respect to a point p includes all nodes in the CFG on a path to p, and so gives a maximal set of relevant nodes that need be considered by our second method. Note that a CFG slice is indeed a slice by denition. Denition 5.2 For a node s, the CFG slice with respect to s, written as SL(CF G; s), is the set of nodes from which there is a path in CFG to s (i.e., all nodes that can reach s via control ow edges): SL(CF G; s) = fw 2 N CF G j w! cf g sg:4 Note that SL(CF G; s) alone yields a substantially larger P slice than SL(AP DG; s) does. Also note that SL(P DG; s) is a subset of SL(CF G; s): there is a path from t to s in PDG only if there is a path from t to s in CFG. The algorithm in Figure 7 computes an executable slice, called SL EX (P DG; s), using the classical PDG and SL(CF G; s). In the gure, Stmt(n) is the statement of the program corresponding to n, and InsertW orklist(n) inserts node n into W orklist if it has not been inserted into W orklist before. Also, for a node n 2 G, Succ(n) = fm j n! m 2 E G g. Once we compute SL EX (P DG; s), we construct P slice from SL EX (P DG; s) the way we construct P slice from SL(AP DG; s), i.e., by adding the exit node and making additions to the label set. As we have already remarked, SL EX (P DG; s) generally yields a smaller P slice than SL(AP DG; s) does. Except for computing P OST DOM, which can be computed in time linear in the size of CFG [8], the cost of computing this version of executable slice is also proportional to the size of the slice. We provide in Appendix a proof that P slice from SL EX (P DG; s) is an executable slice. 4 Note that in this section we use CFG, not ACFG. 14

15 1. Compute P OST DOM : the post-dominator tree of CF G. 2. Compute SL(CF G; s). 3. SLEX(P DG; s) = SL(P DG; s) [ n exit. 4. W orklist = fentryg. 5. While W orklist is not empty (a) Take out node n from W orklist. (b) if n 62 SL(P DG; s) i. Replace Stmt(n) with `goto Stmt(IP DOM(n))' and put it into SLEX(P DG; s). ii. InsertW orklist(ip DOM(n)) (c) else for each m = Succ(n) 2 CF G; m 6= n exit i. if m 2 SL(CF G; s) InsertW orklist(m) ii. else replace Stmt(m) with `goto Stmt(n exit )' and put it into SLEX(P DG; s). 6 Example Figure 7: Algorithm for Executable Slices (Method 2) In this section, we illustrate steps to compute SL EX (P DG; L4), using the second method, for the example in Figure 6. In the illustration, without loss of generality, we regard L1 as Entry and L5 as exit. After Step 3, we have the following sets computed: SL(CF G; L4) = fl1; L2; L3; L4g SL(P DG; L4) = SL EX (P DG; L4) = fl1; L4; L5g: Note that L4 post-dominates L2 and, thus, does not have a (transitive) control dependence on L2; nor does it have a (transitive) data dependence on L2: L2 62 SL(P DG; L4). Also note that IP DOM(L2) = L4. 15

16 After the rst iteration of the loop of Step 5, W orklist, which initially was fl1g, will be fl2g. At Step 5.a, n will be L2, leaving W orklist = fg. Since L2 62 SL(P DG; L4), Steps 5.b.i and 5.b.ii will be executed, replacing Stmt(L2) with Stmt(c L2), which is `goto IP DOM(L2) (= L4)'. It will also put L2 c into SLEX (P DG; L4), which now becomes fl1, cl2, L4, L5 g. W orklist will become fl4g. At the next iteration of Step 5.a, n will be L4, and W orklist will become fg. Since L4 2 SL(P DG; L4), Step 5.c will be executed. However, Succ(L4) = L5 = n exit, and neither Step 5.c.i nor Step 5.c.ii will be executed. Since W orklist = fg, the computation will terminate at this point, leaving SL EX (P DG; L4) = fl1; L2; c L4; L5g; where Stmt(c L2) is `goto L4'. Figure 6 also shows the ACFG of the example code, in which L4 is augmented control dependent on L2. If we apply the rst slicing method of using ACFG to this example, L2 and any statements on which L2 is (transitively) control or data dependent will be in the executable slice. Since L2 read-accesses numerous variables, the size of the resulting executable slice can be substantially larger than the one from the second method illustrated above. 7 Conclusions In this paper, we showed that the classic method for constructing non-executable slices using the PDG cannot be used directly to construct executable slices in the presence of goto statements. The resulting slice omits some needed goto statements, and so is not a correct executable slice. We then presented two methods to produce executable slices, and proved their correctness. The rst uses a CFG augmented with edges and the classic construction technique. Slices constructed using this method have the advantage of always being a subprogram of the original program. However, they are larger than those obtained from the second method, which uses the classical PDG slice. This method augments the PDG slice with additional goto nodes generated from the CFG slice. While this second 16

17 notion of slice is not a subprogram of the original program due to the added goto nodes, its complexity is no worse than linear in the size of the CFG and PDG slice (assuming P OST DOM is already available). Also, as we showed in an example, it can produce much smaller executable slices than the rst method. The choice of method depends on the purpose for which the slice is being used. In either case, we conclude that it is easy to construct executable slices, even in the presence of goto statements. A Appendix Theorem A.1 An augmented slice is a correct executable slice as dened in Denition 4.1. Proof of Theorem A.1 : We rst dene the following terminology: S : the set of statements in SL(AP DG; s) plus the exit statement. i : the i 0 th element (statement trace) in T race(p org ; 0 ), the trace of P org ; i : the i 0 th element in T race(p slice ; 0 ), the trace of P slice ; L : the last element in T race(p slice ; 0 ), which is from the exit statement; ^ i : the i 0 th element in P roj S (P org ; 0 ), which is the projection of T race(p org ; 0 ) onto S; and o(i) : for each ^ i in P roj S (P org ; 0 ), o(i) is its corresponding statement trace in T race(p org ; 0 ). Before we prove Theorem A.1, we prove the following lemma. Lemma A.2 Let S i and S i+1 be the statements that generated ^ i and ^ i+1, respectively. Then, S i+1 postdominates (in ACFG) all the statements that generated j ; o(i) < j < o(i+1). Proof : If not, there will be a statement S j ; o(i) < j < o(i + 1); such that (1) there exists a path P 1 : S j! S i+1 ; (2) there exists a path P 2 : S j! exit that bypasses S i+1 ; and (3) any node strictly between S j and S i+1 in path P 1 does not occur in path P 2. 17

18 In other words, according to Lemma 2.5, S i+1 would be (transitively) augmented controldependent on S j, which would have put j between the two consecutive elements ^ i and ^ i+1 in P roj S (P slice ; 0 ). 2 By the denition of a correct executable slice in Denition 4.1, proving the following lemma is sucient for proving Theorem A.1. Lemma A.3 ^ i = i ; 1 i L. Proof of Lemma A.3 (by induction on trace length): Let ^ 0 and 0 be the empty, and thus identical, initial traces of P org and P slice, respectively. Assume ^ i = i ; 0 i < L, but ^ i+1 (=< S ; >) 6= i+1 (=< S ; >). There are two cases: Case 1: S = S, but 6=. In this case, the same set of variables read-accessed in S have yielded dierent values (given by and ) in the two programs. Since ^ k (= o(k) ) = k ; 0 k i, there should be j, o(i) < j < o(i + 1); of a statement, say S j, that made dierent from by modifying the values of the variable(s) read-accessed by o(i+1) (= ^ i+1 ). In that case, there should be data-dependence edge(s) from S j to S, the statement that generated both ^ i+1 and i+1. However, such S j should belong to P slice, generating a trace between i and i+1. By the inductive hypothesis, there is no such trace between the two and, thus, Case 1 is not possible. Case 2: S 6= S. This case is possible only when there is at least one conditional or unconditional goto statement along the ACFG path from S i to S, where S i is the statement that generated ^ i. Let S k be the statement that generated o(i)+1. Note that (since S 6= S ) there is an ACFG path P : S k! S that does not include S, and an ACFG path P : S k! S that does not include S. According to Lemma A.2, S k is postdominated by S, and therefore S is also postdominated by S. (Otherwise, there would be a path from S k to exit via S that bypasses S.) Since S postdominates S, P bypasses S to exit: there is a path 18

19 P k : S k! S! exit that bypasses S. Therefore, we can nd a statement S j on both P and P such that S is (transitively) augmented control-dependent on S j according to Lemma 2.5. However, such S j should belong to P slice, generating a trace between i and i+1. By the inductive hypothesis, there is no such trace between the two and, thus, Case 2 is not possible.2 We next show that Method 2 in Section 5 is also correct. Theorem A.4 P slice from SL EX (P DG; s) is a correct executable slice (as dened in Denition 5.1). Proof of Theorem A.4 : We rst modify/add the following terminology: S : fs j s 2 P slice \ P org g [ fexitg; ^ i : the i 0 th element in P roj S (P slice ; 0 ), which is the projection of T race(p slice ; 0 ) onto S; and ^ L : the last element in P roj S (P slice ; 0 ). The proof that P slice is a correct executable slice follows from Lemma A.7 provided below. Before Lemma A.7, we introduce a few lemmas. Lemma A.5 Let P i : n 1! n 2 : : :! n p be a CFG path such that n p post-dominates n 1 ; : : : ; n p?1. Then, IP DOM(n 1 ) 2 fn 2 ; : : : ; n p g. Proof: Let ^n = IP DOM(n 1 ). Both ^n and n p post-dominate n 1. However, since ^n immediately post-dominates n 1, n p is not post-dominated by ^n. Therefore, there exists a path P j : n p! n exit that by-passes ^n. If ^n 62 fn 2 ; : : : ; n p g, there exists a path to n exit consisting of the concatenation of the two paths, P i P j, that by-passes ^n, which contradicts that ^n (immediately) post-dominates n

20 Lemma A.6 Let P i : n 1! n 2 : : :! n p be a CFG path such that n p post-dominates n 1 ; : : : ; n p?1. Then, there exist a set of nodes f^n 1 ; : : : ; ^n M g fn 1 ; : : : ; n p g such that ^n 1 = n 1 ; ^n M = n p ; and ^n j = IP DOM(^n j?1 ); 1 < j M: Proof (By induction): According to Lemma A.5, IP DOM(^n 1 ) = IP DOM(n 1 ) 2 fn 2 ; : : : ; n p g. Thus, we can pick ^n 2 = IP DOM(^n 1 ), such that ^n 2 2 fn 2 ; : : : ; n p g. Assume ^n i = IP DOM(^n i?1 ) = n k 2 fn 2 ; : : : ; n p g: Then, according to Lemma A.5, ^n i+1 = IP DOM(^n i ) = IP DOM(n k ) 2 fn k+1 ; : : : ; n p g: Repeat this until ^n i = n p. 2 We now return to Lemma A.7. Lemma A.7 ^ i = ^ i ; 1 i L: Note that ^ i and ^ i ; 1 i L, are, respectively, elements in the projections of T race(p org ; 0 ) and T race(p slice ; 0 ) and, therefore, do not contain statement traces of additional goto statements inserted by the algorithm. Proof of Lemma A.7: Let o(i) be the trace in T race(p org ; 0 ) corresponding to ^ i, and o(i) be the trace in T race(p slice ; 0 ) corresponding to ^ i. We will prove the lemma by proving that o(i) = o(i) ; 1 i L: In the following proof, S i and S i are the statements that generate i and i, respectively. Let 0 and 0 be the empty, and thus identical, initial traces of P org and P slice, respectively. 20

21 Thus, o(0) (= 0 ) = o(0) (= 0 ). Assume o(i) = o(i) ; 0 i < L; we show that o(i+1) = o(i+1). Let o(i)+1 =< S o(i)+1 ; o(i)+1 >, and o(i)+1 =< S o(i)+1 ; o(i)+1 >. Case 1: o(i)+1 = o(i+1) In this case, S, which is in SL(P DG; s), is o(i+1) S o(i)+1, which is a successor in CFG of S o(i). Since every successor in CFG of S o(i) that is in SL(P DG; s) is in P slice, S o(i+1) is one of the successors of S in P o(i) slice. Note that S in P o(i) slice is equal to S. Since the o(i) traces up to o(i) and o(i) are the same, the next statements executed after those of o(i) and o(i) (S o(i) and S o(i) respectively) are the same, and this statement is S o(i+1), both will generate the same traces. Therefore, o(i+1) = o(i+1). Case 2: o(i)+1 6= o(i+1) ; S o(i)+1 62 SL(CF G; s) In this case, there is no CFG path from S to s, according to the denition of CFG o(i)+1 slice. Neither is there a CFG path from S j ; o(i) < j o(l), which are successors of S o(i)+1, to s; otherwise, there will be a CFG path from S o(i)+1 to s. Therefore, j; o(i) < j o(l), are not generated by statements in SL(CF G; s). Nor are they generated by statements in SL(P DG; s), since SL(P DG; s) is a subset of SL(CF G; s). Thus, o(i+1) = o(l). When S o(i)+1 62 SL(CF G; s), by construction, the statement of o(i)+1 will be `goto exit', which has replaced S o(i)+1. Therefore, o(i+1) = o(l) = o(l). Case 3: o(i)+1 6= o(i+1) ; S o(i)+1 2 SL(CF G; s) In this case, according to Lemma A.2, S o(i)+1 : : : S o(i+1)?1 must be post-dominated by S o(i+1). According to Lemma A.6, IP DOM(S o(i)+1 ) is one of S o(i)+2 : : : S o(i+1). Therefore, there is a set of statements f ^S1 : : : SN ^ g fs : : : o(i)+1 S o(i+1) g such that ^S 1 = IP DOM(S o(i)+1); ^S N = IP DOM( ^S N?1 ) = S o(i+1); and ^S j+1 = IP DOM( ^S j ); 1 j < N: 21

22 By the slicing algorithm, S will be replaced with `goto ^S1 '; ^Sj will be replaced o(i)+1 with `goto ^S j+1 '; and ^S N?1 will be replaced with `goto ^S N ', which is S. These o(i+1) `goto' statements correspond to the statements executed generating traces between o(i)+1 and o(i+1). Therefore, o(i+1) = o(i+1). 2 ACKNOWLEDGEMENT We would like to thank the referees for their helpful and careful comments, which have substantially improved the presentation and content of the paper. References [1] H. Agrawal. On slicing programs with jump statements. Proceedings of the ACM SIGPLAN '94 Symp. on Programming Lang. Design and Implementation, June [2] H. Agrawal and B. Horgan. Dynamic program slicing. Sigplan Notices, 25(6):246{256, June Proceedings of the ACM SIGPLAN '90 Symp. on Programming Lang. Design and Implementation. [3] Tom Ball and Susan Horwitz. Slicing programs with arbitrary control-ow. In Proc. of the 1st International Workshop on Automated and Algorithmic Debugging, Linkoping, Sweden, May 1993 (to appear in Lecture Notes in Computer Science #749), pages 206{ 222. Springer-Verlag, November

23 [4] Jong-Deok Choi, Barton P. Miller, and Robert H. B. Netzer. Techniques for debugging parallel programs with owback analysis. ACM Transactions on Programming Languages and Systems, 13(4):491{530, October [5] Ron Cytron, Jeanne Ferrante, Barry K. Rosen, Mark N. Wegman, and F. Kenneth Zadeck. Eciently computing static single assignment form and the control dependence graph. ACM Transactions on Programming Languages and Systems, October [6] J. Ferrante, K. Ottenstein, and J. Warren. The program dependence graph and its use in optimization. ACM Transactions on Programming Languages and Systems, pages 319{349, July [7] K. B. Gallagher. Using Program Slicing in Software Maintenance. PhD thesis, University of Maryland, [8] D. Harel. A linear time algorithm for nding dominators in ow graphs and related problems. Proceedings of the 17th ACM Symposium on Theory of Computing, pages 185{194, May [9] Susan Horwitz, Jan Prins, and Thomas Reps. Integrating non-interfering versions of programs. ACM Transactions on Programming Languages and Systems, 11, 3:345{387, July [10] Susan Horwitz, Thomas Reps, and David Binkley. Interprocedural slicing using dependence graphs. ACM Transactions on Programming Languages and Systems, 12,13:26{60, January [11] B. Korel and J. Laski. Dynamic program slicing. Information Processing Letters, 29:155{ 163, October

24 [12] D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe. Dependence graphs and compiler optimizations. Conference Record of 8th ACM Symposium on Principles of Programming Languages, [13] J. R. Lyle. Evaluating Variations of Program Slicing for Debugging. PhD thesis, University of Maryland, [14] Karl J. Ottenstein and Linda M. Ottenstein. The program dependence graph in a software development environment. Software Engineering Notes, 9(3), Also appears in Proceedings of the ACM Symposium on Practical Programming Development Environments, Pittsburgh, PA, April, 1984, and in SIGPLAN Notices, Vol. 19, No 5, May, [15] Tom Reps and Wuu Yang. The semantics of program slicing and program integration. Proceedings of the Colloquium on Current Issues in Programming Languages, Barcelona, Spain, March 13-17, 1989 (also appeared in Lecture Notes in Computer Science), March [16] Vivek Sarkar. The PTRAN parallel programming system. In B. Szymanski, editor, Parallel Functional Programming Languages and Compilers, pages 309{391. ACM Press Frontier Series, [17] Mark Weiser. Program slicing. IEEE Transactions on Software Engineering, SE(10)- 4:352{357, July