Zadeck, F.K., "Incremental data flow analysis in a structured program editor," Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, (Montreal, Can., June 20-22, 1984), ACM SIGPLAN Notices 19(6) pp. 132-143 (June 1984).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....cycle. Potentially, the algorithm would not terminate. This was our concern when disallowing cloning within recursive cycles. We now understand how to support recursion. First, strongly connected regions are located in the call multigraph, and each cycle is replaced with a representative node [Zad84] When the algorithm reaches a node representing a cycle, it must take each incoming CloningVector and propagate it within nodes in the recursive cycle until the CloningVector information stabilizes. The CloningVectors resulting from the propagation, which may contain less information than the ....

....preserve topological order, as explained later. 110 Execution frequency estimates With the edge annotations, EdgeFrequency and NodeFrequency are calculated. First, assume that the cycles in the call multigraph have been located, and nodes appearing in a cycle are collapsed into a single node [Zad84] Secondly, assume that a topological ordering of the nodes in the reduced graph is available. NodeFrequency(n) is initialized to 1 for the main procedure. To deal with the possibility of cycles in the call multigraph (denoting recursion) we locate cycles and eliminate back edges from our ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, June 1984.

.... a single source statement deletion (iii) acceptable precision (about 75 of tests had the same solution from the incremental and exhaustive algorithms) Related Work Many incremental algorithms have been developed for data flow analysis, which are useful, especially in a programming environment [Zad84] Some incremental analyses use incremental elimination methods [Bur90, CR88, RP88] some are based on the technique of restarting iteration [CK84, PS89] and some are a combination of these two techniques [MR90] When a change is made, restarting iteration is a good mechanism for reusing the ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN Symposium on Compiler Construction, pages 132--143, June 1984. SIGPLAN Notices, Vol 19, No 6.

....of data usage in the program. Compile time analysis provides potentially useful information which can be utilized to insure the safety of program optimizations and transformations. Analysis information is also essential for data flow based testing [10, 12, 13, 18, 29, 31] semantic change analysis [5, 28, 33, 34, 35, 42, 43], integration of program versions [16, 17, 41] and various other optimizations, such as run time check elision [1] e.g. verifying that variables are initialized before they are used) In languages with general purpose pointer usage, two names may access the same location during execution; they ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN Symposium on Compiler Construction, pages 132--143, June 1984. SIGPLAN Notices, Vol 19, No 6.

....to the work necessary to perform the updates. These calculations show that incremental analysis will be substantially cheaper than total reanalysis. Related Work Many incremental algorithms have been developed for the data flow analysis, which are useful, especially in a programming environment [Zad84]. Some incremental analyses use incremental elimination methods [Bur90, CR88, RP88] some are based on the technique of restarting iteration [CK84, PS89] When a change is made, restarting iteration from the previously computed solution does not always yield a precise solution. RMP88] shows some ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN Symposium on Compiler Construction, pages 132--143, June 1984. SIGPLAN Notices, Vol 19, No 6.

....transfer functions are distributive. Notably, the iterative algorithm, like most other dataflow algorithms, computes F(n) for each and every node in N even though we only need F(op) the dataflow attributes of the op node. 6 Partitionable frameworks: A dataflow framework (L; F ) is partitionable [23] if we can split the framework into a finite number of independent frameworks (L i ; F i ) each inducing a separate dataflow problem, and obtain the solution to the original problem simply by grouping all the individual solutions together. For 5 DDFA assumes a well founded (finite height) ....

F.K. Zadeck. Incremental dataflow analysis in a structured program editor. In SIGPLAN Symposium on Compiler Construction, 1984. 28

.... Algebraic properties of functions in F (viz. monotonicity, distributivity, continuity, etc. 32] Finiteness properties of functions in F (viz. boundedness [44] fastness [31] rapidity, 36] etc. Finiteness properties of L (viz. height [32, 44] Partitionability properties of L and F [63]. There is an important subclass of k bounded partitionable problems 2 called the bit vector problems [32] which has been extensively discussed in the literature [25, 32, 44, 46] though it is defined only informally (viz. in [32, 63] We provide a formal definition in section 3.1.3 and use it ....

....L (viz. height [32, 44] Partitionability properties of L and F [63] There is an important subclass of k bounded partitionable problems 2 called the bit vector problems [32] which has been extensively discussed in the literature [25, 32, 44, 46] though it is defined only informally (viz. in [32, 63]) We provide a formal definition in section 3.1.3 and use it in the exposition of our theory. 2.2 Data Flow Equations To formulate a data flow problem, the data flow properties associated with each node of the flow graph are represented as variables which, as noted earlier, are elements in L . ....

[Article contains additional citation context not shown here]

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of SIGPLAN'84 Symposium. on Compiler Construction, pages 132--143, 1984. Also Published as SIGPLAN Notices, 19(6).

....in label defs refs and which do not define labels which are referenced in label defs refs. Slicing is simply performed by putting a specific annotation on these nodes. Once this is done, the usual resolution of gotos is achieved, ignoring tree nodes which have been sliced off. As shown by Zadeck [Zadeck83], the work we have done for control flow analysis can adapted to deal with a certain class of data flow problems. However such a method suffers from the fact that slice derivation is not automatic, in the sense that one has to write a specific sliced set of rules for every new problem. We ....

K. Zadeck, "Incremental Data Flow Analysis in a Structured Program Editor" Ph.D. Thesis, Rice University, October 1983.

....propagates cloning vectors for all calls to a procedure and renames the variables in each cloning vector according to the parameter passing at its corresponding call. For recursive cycles, we locate stronglyconnected regions in the call graph and replace the cycle with a representative node [17]. This step ensures correctness of the cloning and allows propagation to occur in a single pass over the call graph. When the algorithm reaches a node representing a cycle, it must take each incoming cloning vector and propagate it within nodes in the recursive cycle until its information ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, SIGPLAN Notices 19(6), pages 132--143. ACM, June 1984. Page 10

....analysis. Like reaching definitions, CCP is a distributive problem. However, unlike reaching definitions, CCP cannot be broken into a separate analysis for each variable. This property of reaching definitions analysis, which simplifies the analysis algorithm, was termed partitionable [Zadeck 1984] or locally separable [Reps et al. 1995] 5.5 Specialized Queries and Propagation Rules An instance of the demand driven framework for CCP is obtained by specializing the three framework components: 1) the query definition, 2) the query propagation rules, and (3) the generic analysis ....

Zadeck, F. 1984. Incremental data flow analysis in a structured program editor. In Proceedings of the 1984 SIGPLAN Symposium on Compiler Construction. ACM, New York, 132--143.

....substantially cheaper than exhaustive reanalysis with a limited sacrifice of the precision. 1 For other pointer aliasing algorithms, see [YRL98] Related Work Many incremental algorithms have been developed for the data flow analysis, which are useful, especially in a programming environment [Zad84] Some incremental analyses use incremental elimination methods [Bur90, CR88, RP88] some are based on the technique of restarting iteration [CK84, PS89] and some are a combination of these two techniques [MR90] When a change is made, restarting iteration is a good mechanism for reusing the ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN Symposium on Compiler Construction, pages 132--143, June 1984. SIGPLAN Notices, Vol 19, No 6.

....then identify all variables that get modified through dereference of a pointer using the found aliases [SH97a, ZRL96, ZRL98, YRL98] 3. 3 Incremental Data Flow Analyses Many incremental algorithms have been developed for data flow analysis, which are useful, especially in a programming environment [Zad84] Some incremental analyses use incremental elimination methods [Bur90, CR88, RP88] some are based on the technique of restarting iteration [CK84, PS89, YRL99] and some are a combination of these two techniques [MR90] An incremental elimination method first partitions the flow graph, and then ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN Symposium on Compiler Construction, pages 132--143, June 1984. SIGPLAN Notices, Vol 19, No 6.

....in the same time as a 1 semibounded problem. Lemma 71 The total time for solution of a SigCnt lattice problem using Tarjan s path expression algorithm is O(jN j 2 jSigsj) in the worst case. Proof: Direct from Lemmas 10, 66, 68 and 69. 2 A similar node splitting operation is used by Zadeck [Zade84] to prove that a class of lattice frameworks O(jN j jEj) assuming that the time to perform a meet operation is constant. Zadeck s node functions (and therefore his edge functions) are either constant valued or nonincreasing and distributive; nodes with constant valued outputs are split, as in ....

Zadeck, F. K. "Incremental data flow analysis in a structured program editor." ACM SIGPLAN '84 Symposium on Compiler Construction. In ACM SIGPLAN Notices, 19:6, June 1984, 132-143.

....need to incrementally update the control flow, control dependence, SSA, and call graphs, as well as recalculate live range, constant, symbolic, interprocedural, and dependence testing information. Several algorithms for incremental analysis can be found in the literature; e.g. dataflow analysis [47, 58], interprocedural analysis [10, 46] interprocedural recompilation analysis [11] as well as dependence analysis [45] However, few of these algorithms have been implemented and evaluated in an interactive environment. Rather than tackle all these problems at once, we chose a simple yet practical ....

F. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the SIGPLAN '84 Symposium on Compiler Construction, Montreal, Canada, June 1984.

....on the strong component condensation. It can handle irreducible flow graphs by application of fixed point iteration within components [MR90] In addition to the above general purpose algorithms, there is a family of data flow solution procedures called the partitioned variable technique (PVT) Zad84] A PVT algorithm partitions a data flow problem by variables and finds the relevant information for a single variable, one at one time. The technique is only applicable to a small set of intraprocedural problems, and is not general purpose. 2.3 Parallel Machines A parallel machine usually ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN '84 Symposium on Compiler Construction, pages 132--143. ACM Press, June 1984. Montreal, Canada.

....interprocedural dataflow analysis and interprocedural slicing problems would be to use the programs from Sections 3 and 4 in conjunction with the SUNY Stony Brook XSB system [40] 6. 1 Dataflow Analysis Previous work on demand driven dataflow analysis has dealt only with the intraprocedural case [3, 43]. The work that has been reported in the present paper 28 Chapter 1 complements previous work on the intraprocedural case in the sense that our approach to obtaining algorithms for demand driven dataflow analysis problems applies equally well to intraprocedural dataflow analysis. However, in ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, pages 132--143, Montreal, Can., June 1984. Appeared in SIGPLAN Notices 19, 6 (June 1984).

....approach, extensible to discover redundancies due to common subexpressions enabling further reductions in an equation system. Other methods that improve data flow analysis by building specialized program graphs are applicable to only certain data flow problems. The partitioned variable technique [Zad84] constructs for each variable a simplified flow graph that enables a fast evaluation of the solution. However, this method is restricted to partitionable data flow problems that permit the analysis of each variable partition in isolation. The global value graph [RL77, RT82] static single ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In Proc. ACM SIGPLAN Symp. on Compiler Construction, pages 132--143, June 1984. This article was processed using the L a T E X macro package with LLNCS style

....single assignment graph (ssa) CFR 89] and call graphs, as well as recalculate scalar live range, constant, symbolic, interprocedural, and dependence testing information. Several algorithms for performing incremental analysis are found in the literature; for example, data flow analysis [RP88, Zad84] interprocedural analysis [Bur90, RC86] interprocedural recompilation analysis [BCKT90] as well as dependence analysis [Ros90] However, few of these algorithms have been implemented and evaluated in an interactive environment. Rather than tackle all these problems at once, we chose a simple ....

F. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the SIGPLAN '84 Symposium on Compiler Construction, Montreal, Canada, June 1984. 156

....in the same time as a 1 semibounded problem. Lemma 76 The total time for solution of a D SigCnt lattice problem using Tarjan s path expression algorithm is O(jN j 2 jSigsj) in the worst case. Proof: Direct from Lemmas 13, 71, 73 and 74. 2 A similar node splitting operation is used by Zadeck [Zad84] to prove that a class of lattice frameworks O(jN j jEj) assuming that the time to perform a meet operation is constant. Zadeck s node functions (and therefore his edge functions) are either constant valued or nonincreasing and distributive; nodes with constant valued outputs are split, as in ....

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN '84 Symposium on Compiler Construction, pages 132--143, June 1984.

....execution state that holds whenever that point is reached during execution. By contrast, a demand program analysis algorithm computes a partial solution to a problem, when only part of the full answer is needed e.g. whether a particular fact (or set of facts) holds at a single specific point [6, 52, 36, 12, 37, 24, 44]. Demand analysis can sometimes be preferable to exhaustive analysis for the following reasons: Narrowing the focus to specific points of interest. In program optimization, most of the gains are obtained from making improvements at a program s hot spots , such as the innermost loops, which means ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In ACM Symposium on Compiler

.... if ( c, d 4 ) succ 1 (c) d 5 ) SummaryEdge then [29] Insert ( c, d 4 ) succ 1 (c) d 5 ) into SummaryEdge [30] for each d 3 such that ( s fg(c) d 3 ) c, d 4 ) PathEdge do [31] Propagate(PathEdge, s fg(c) d 3 ) succ 1 (c) d 5 ) WorkList) 32] od [33] fi [34] od [35] od [36] end case [37] case n (N p Call p e p ) 38] for each (m, d 3 )such that ( n, d 2 ) m, d 3 ) E # do [39] Propagate(PathEdge, s p , d 1 ) m, d 3 ) WorkList) 40] od [41] end case [42] end switch [43] od end Figure4. The Tabulation Algorithm determines the ....

.... [27] WorkList : 28] for each (s main , c) C # do [29] Insert ( s main , c) s main , c) into RealizablePath [30] Insert ( s main , c) s main , c) into WorkList [31] od [32] while WorkList do [33] Select and remove anedge ( s main , c) n, d 1 ) from WorkList [34] switch n [35] case n Call p : 36] for each d 2 such that ( n, d 1 ) s calledProc(n) d 2 ) E # do [37] Propagate(RealizablePath, s main , c) s calledProc(n) d 2 ) WorkList) 38] od [39] for each d 2 such that ( n, d 1 ) succ 1 (n) d 2 ) E # SummaryEdge) do [40] ....

[Article contains additional citation context not shown here]

Zadeck, F.K., "Incremental data flowanalysis in a structured program editor," Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, (Montreal, Can., June 20-22, 1984),ACM SIGPLAN Notices 19(6) pp. 132-143 (June 1984).

....propagation for a single program variable. clude the values of variables or formal parameters that occur in array subscript expressions or in loop bounds. Determining that a variable v is a copy constant requires the simultaneous analysis of all programs variables. CCP is not a partitionable [Zad84] analysis that would permit the separate analysis of each variable as, for example, is possible in live variable analysis. The CCP lattice for a program with k variables is the product L k , where the component lattice L is defined as shown in Figure 2. Thus, each lattice element x 2 L k is a ....

....with respect to even the exhaustive solutions. An interesting combination of the two approaches would be to use, for example, a reduced equation system according to [DGS94] or a sparse evaluation graph as in [CCF90] as the basis for propagating data flow queries. Incremental data flow analysis [Ros81, Zad84, RP88, PS89] has also addressed the avoidance of exhaustive solution recomputations. However, unlike demand driven analysis, incremental analysis assumes that an exhaustive solution has previously been computed and is concerned with avoiding exhaustive re computations in response to program changes. 7 ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In SIGPLAN Symp. on Compiler Construction, pages 132--143, Jun. `84.

.... algorithms, there is a family of data flow solution procedures for specific intraprocedural problem called the partitioned variable technique (PVT) these partition the solution of a data flow problem by variables and find the relevant information for a single variable, one at a time [Zad84]. 2.2 Parallel Hybrid Data Flow Algorithm Our parallel hybrid data flow analysis algorithms are fashioned from the sequential hybrid algorithm described briefly above by finding algorithmic parallelism in the solution process. The parallel hybrid algorithm is organized in a master worker model ....

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN '84 Symposium on Compiler Construction, pages 132--143. ACM Press, June 1984. Montreal, Canada.

No context found.

Zadeck, F.K., "Incremental data flow analysis in a structured program editor," Proceedings of the SIGPLAN 84 Symposium on Compiler Construction, (Montreal, Can., June 20-22, 1984), ACM SIGPLAN Notices 19(6) pp. 132-143 (June 1984).

No context found.

F.K. Zadeck. Incremental data flow analysis in a structured program editor. In ACM Symposium on Compiler

No context found.

F.K. Zadeck. 1984. Incremental data flow analysis in a structured program editor. SIGPLAN Notices 19(6):132--143.

No context found.

F. K. Zadeck. Incremental data flow analysis in a structured program editor. In Proceedings of the ACM SIGPLAN '84 Symposium on Compiler Construction, pages 132--143, June 1984.

No context found.

F. K. Zadeck. Incremental Data Flow Analysis in a Structured Program Editor. PhD thesis, Department of Mathematical Sciences, Rice University, 1983.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC