Burke, M. An interval-based approach to exhaustive and incremental interprocedural analysis. Tech. Rep. RC 12702, IBM Research Center, Yorktown Heights, NY, Sept. 1987.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....is small. If this is the case, then analysis with partial transfer functions can be a highly effective way to reduce analysis time. sit is possible to use a summary based technique on such recursive call graphs, essentially computing second order transfer functions, reducing the time further ([20]) but fewer analysis problems are amenable to such techniques. The concept of partial transfer functions (PTF) is important as it allows summary techniques, an idea long used by compiler writers in solving simpler data flow prob lems, to be applied to more complex program analysis involving ....

M. Burke. An interval-based approach to exhaustive and incremental interpro- cedural data-flow analysis. A CM Transactions on Programming Languages and Systems, 12(3):341 395, July 1990.

....requiring the lookup of a single bit but has the disadvantage of requiring large amounts of space. Since we need di erent bit vectors for di erent regions, this only compounds the space problem. Yet we opt for the second method with the following modi cation. We use an interval based approach [4] to generate the Path bit vectors. This requires reducing each strongly connected region (SCR) in the TCFG to a single node. The resultant graph is acyclic and the Path bit vectors can be found during a single topological order traversal of the reduced graph. Since every node within a strongly ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data- ow analysis. #######, 12(3):341-395, July 1990.

....takes place. We learned of the application of logic programming to program analysis from [10] 1.1 Incremental program analysis Data ow analysis Many incremental algorithms have been developed for general data ow analysis. The two leading techniques are incremental elimination methods [5 7, 34], and the technique of restarting iteration [9, 30] These two approaches are not exclusive, however, and can be combined [29] A common problem, especially with restarting iteration, is that the solution for the updated problem instance is not as precise as the one returned by iteration from ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data ow analysis algorithms. ACM Transactions on Programming Languages and Systems, 12(3):341-395, 1990.

....Section 3 presents the algorithm, and Section 4 gives an example that exercises all of the steps of the algorithm. In Section 5, we prove correctness of the algorithm, and Section 6 proves its time complexity. Section 7 discusses previous work, including a comparison with two existing algorithms [Bur87] CCHK90] Section 8 summarizes the chapter. 2.1 Background and Definitions Since processing statically bound calls, i.e. calls invoking procedure constants) is straightforward, the challenge is to add edges representing dynamically bound calls through procedure variables. This requires that ....

....algorithm is O(N EP ) Although P N , in our experience with fortran this number is almost always 1, so we expect the algorithm to have linear behavior in practice. 2.6 Related Work 2.6.1 Comparison with Burke s Algorithm Figure 2. 5 presents a summary of the algorithm proposed by Burke [Bur87] The set ActualBound(f) represents all procedure constants that can be bound to a procedure 27 parameter f that is invoked. For procedure parameters that are not invoked, it contains only those values directly bound to the procedure parameter (and not those bound through a chain of calls) The ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural analysis. Research Report RC 12702, IBM Yorktown Heights, September 1987.

.... interprocedural side e#ects is crucial for aggressive compiler optimization [ASU86] practical dependence analysis in programs with procedure calls [Ban88, Pol88, Wol89] data flow based testing [HS91, BH93, HFGO94, Ost90, Wey94, CR99, FW93, FI98] incremental semantic change analysis of software [Bur90, BR90, CR88, CK84, MR90a, MR91, PS89, Ryd83, RP88, YRLS97, YRL99] interprocedural def use relations [PLR94, HS94, GH98, CR99, Cha99] and e#ective static interprocedural program slicing [GL91, HRB90, OO84, RR95, GS96, LH96, HC98, SHR99, TCFR96, Tip96, Ven91, Wei84, TAFM97, AG96, AG98] Many of ....

.... program point specific side e#ect information in the presence of pointers in order to handle modern languages such as C, C , FORTRAN90 and Java; 2 this requires practical interprocedural side e#ect analysis with pointers, something that previous techniques for FORTRAN cannot supply [Ban79, Bur90, Coo85, CK88, CK87] In the past, it has been suggested that one could do intraprocedural analyses of C codes, by using worst case estimates of variables which could possibly experience a side e#ect at a call site. This yields a safe approximation of side e#ect information, but almost surely ....

[Article contains additional citation context not shown here]

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....to the TD problem. The CGC problem too is, therefore, intractable. Any polynomial algorithm for it can only give approximate results. The algorithm presented makes the following contributions: 1. It constructs call graphs for a larger class of procedural language programs than previous algorithms [Bur87, CCHK90, HK93, Lak93, Wei80, Spi71, Ryd79]. 2. When compared under suitable mapping, the results of our algorithm are more precise than Pande and Ryder s type determination algorithm for C [PR93] 3. When compared under suitable mapping, our algorithm is equivalent to Shivers 1CFA [Shi88, Shi91b] Our algorithm is however a) more ....

....[Shi88, Shi91b] The CGC algorithms may be compared on a) the programming language they are applicable for and b) the precision of the call graph they construct. Due to the difference in their domain and results, comparing their computational cost is not meaningful. The algorithms of Burke [Bur87], Callahan et al. CCHK90] Hall Kennedy [HK93] and Ryder [Ryd79] are applicable for Fortran like languages in which a) only formal parameters 9 November 4, 1993 can be procedure valued variables, b) these formal parameters can not be assigned to, and c) procedure references can only be used ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural analysis. Technical Report RC 12702, IBM Research Center, Yorktown Heights, NY, September 1987.

....flow analysis has been in progress, probably, ever since the first compiler was written. As a result it is beyond the scope of this document to perform an exhaustive survey of the field. The reader is referred to [2, 18, 28] for a detailed survey. The work in interprocedural data flow analysis [3, 6, 7, 11, 25, 27, 38] is of interest from the point of view of this paper. Interprocedural analyses answer questions such as if the value of a variable is changed at statement in procedure will it affect the computation of statement in procedure . We are only interested in static analysis, i.e. ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural analysis. ACM Trans. Prog. Lang. Syst., 12(3), July 1990.

....and fusion using shared write sets. The dataflow variables in the Figure1 take values of shared write sets. The logical operations are considered as set operations. Just after points to analysis, each write set includes only one write commitment, i.e. s = 1; C = We use interval analysis[14, 15] to calculate dataflow equations. We create a summary of each interval or call site in a bottom up manner. Coalescing and redundant index elimination are applied to a summary of an interval and to a summary of a call site which is created by a parameter mapping on a summary of a procedure. Fusion ....

M. Burke. An Interval-Based Approach to Exhaustive and Incremental Interprocedural DataFlow Analysis. ACM Trans. on Programming Languages and Systems, 12(3):341--395, July 1990.

....around the write commitment. A dataflow variable takes a set of write sets. The logical operations in the above dataflow equations are considered as set operations. Just after points to analysis, each write set includes only one write commitment, i.e. s = 1; C = 0. We use interval analysis[9, 5] to calculate dataflow equations. In interval analysis, CFG is represented hierarchically with interval (i.e. loop) structures. When a summary of interval is propagated outward, inequalities which represent induction variables are added to C. We describe optimizing methods to combine multiple ....

M. Burke. An Interval-Based Approach to Exhaustive and Incremental Interprocedural Data-Flow Analysis. ACM Trans. on Programming Languages and Systems, 12(3):341-- 395, July 1990.

.... an increasing focus on interprocedural optimizations in compilers for imperative and object oriented languages and with an increasing use of results of interprocedural program analysis in software development environments, the problem of call graph construction has received a significant attention [3, 5, 6, 10, 11, 13, 14, 18, 23, 22, 24, 25, 27, 29, 28, 30, 31, 33]. A call graph is a static representation of dynamic invocation relationships between procedures (or functions or methods) in a program. A node in this directed graph represents a procedure and an edge (p q) exists if the procedure p can invoke the procedure q [2] In objectoriented languages, a ....

....Lin and Padua [20] They have presented techniques for computing reaching properties of an array on a demand basis. Again, their work assumes that a call graph has already been constructed. The existing work in the area of call graph analysis is restricted to performing exhaustive analysis only [3, 5, 6, 10, 11, 13, 14, 18, 23, 22, 24, 25, 27, 29, 28, 30, 31, 33]. We are not aware of any previous work on performing demand driven construction of call graphs. 7 Conclusions We have presented design and evaluation of an algorithm for resolving call sites in an object oriented program on a demand driven fashion. The summary of our results using SPECJVM ....

Michael Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....analysis, we would have preferred to start with a conservative solution and then add further elements. However, this is not feasibly while performing demand analysis, because of the way the initial conservative call graph is constructed. The previous work in the area of call graph construction [2, 3, 4, 7, 8, 10, 11, 12, 15, 19, 18, 20, 21, 23, 25, 24, 26] has only focussed on exhaustive analysis and has not considered demand driven analysis. Similarly, the previous work in the area of demanddriven data flow analysis [9, 14] has assumed that a complete call graph has already been constructed before initiating the demand driven analysis. 6 ....

Michael Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....it is reasonable to assume that variables local to the caller will not change. Such assumptions limit the extent that transfromations can be performed. Techniques are available to extract more detailed information: to determine parameter aliasing and effects of procedures on global variables, see [7, 8, 9, 19, 37, 42]; to determine pointer aliasing, see [14, 15, 27, 29, 33, 34, 44] When a sophisticated analysis technique is applied, the usual result is that there are few side effects and the tuples (both LHS and RHS) are small. Small tuples can be represented directly. Sophisticated analysis, however, is ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Trans. on Programming Languages and Systems, 12(3):341--395, July 1990.

.... 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 previously computed information. However, a precise solution for the ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....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 su#cient conditions under which restarting iteration results in the same solution ....

....methods. A hybrid incremental algorithm for the reference parameter aliasing problem of Fortran is proposed in [MR91] For the MOD problem for Fortran like languages, e# cient flow insensitive algorithms are proposed in [CK84, Coo85] and the incremental MOD problem for Fortran was handled in [Bur90]. The incremental MOD problem for C is more complicated than its counterpart for Fortran mainly because the pointer aliasing information for C may change inter and intra procedurally. BACKGROUND AND DEFINITIONS MOD Problem for C The MOD problem ascertains how program execution may a#ect the ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....one for aliases. Cooper and Kennedy [Coo85, CK84, CK87] further decomposed the problem into side effects on global variables and side effects accomplished through parameter passing. Burke showed that these two subproblems on globals and formals can be solved by a similar problem decomposition [Bur90]. Choi, Burke, and Carini mention a modification side effects algorithm for languages with pointers based on their flow insensitive pointer aliasing calculation [CBC93] it is difficult to compare our work to theirs, because they give no description of their algorithm. Clearly, the importance of ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....analysis algorithm that considers loop nesting hierarchies is interval analysis. It can be used for forward problems, such as available expressions [All70, Coc70] and backward problems, such as live variables) Ken71] and it has also been used for code motion [DP93] and incremental analysis [Bur90] We are using a variant of interval analysis that is based on Tarjan intervals [Tar74] Like Allen Cocke intervals, a Tarjan interval T (h) is a set of control flow nodes that corresponds to a loop in the program text, entered through a unique header node h, where h 62 T (h) However, Tarjan ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....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 previously computed information. However, a precise solution for the ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

.... to report program point specific side effect information in the presence of pointers in order to handle modern languages such as C, C , Fortran90 and Java; this requires practical interprocedural side effect analysis with pointers, something that previous techniques for FORTRAN cannot supply [1, 4, 5, 2]. A family of side effect analyses for C, parameterized by the pointer aliasing algorithm used, has been defined [11, 10] these analyses vary in the cost precision tradeoffs for the calculated sideeffect information. Using different combinations of flow sensitive and or context sensitive ....

....and a separate one for aliases. Cooper and Kennedy [4, 5] further decomposed the problem into side effects on global variables and side effects accomplished through parameter passing. Burke showed that these two subproblems on globals and formals can be solved by a similar problem decomposition [2]. All of this work targeted the programming model of Fortran and related languages with no pointer usage. Choi, Burke, and Carini mention an interprocedural modificationside effects algorithm for languages with pointers based on their flow sensitive pointer aliasing technique [3, 12] it is ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....I, and P R 2 corresponds to the subscript expression 2 I. Using F L 2 and the first rule in Table 1, F R 2 (j) is set to j 2 1. The mapping descriptor thus obtained maps B(2 I) onto VPROCS(J, I 1) 3. 2 Interval Based Data Availability Analysis Interval analysis is precisely defined in [6]. An interval corresponds to a program loop. Each interval has a header node h, a last node l, and a single backedge hl; hi. The analysis for structured (reducible) control flow graphs is performed in two phases, an elimination phase and a propagation phase. Elimination Phase The elimination ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....PPOUT i . Finally, there is a forward correction pass that determines PP IN i . During the final pass, INSERT i and REDUND i are also determined for each node. We now describe how we use interval analysis to handle loops in the program. INTERVAL ANALYSIS Interval analysis is precisely defined in [4]. The analysis is performed in two phases, an elimination phase and a propagation phase, that are explained below. We use Tarjan intervals [21] which correspond to program loops. Given a structured program, each interval has a unique header node h. As a further restriction, we require each ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....a back edge hl; hi. The edge splitting transformation, discussed earlier, adds a node b to split the back edge hl; hi into two edges, hl; bi and hb; hi. We now describe how interval analysis is used in the overall data flow procedure. INTERVAL ANALYSIS Interval analysis is precisely defined in [5]. The analysis is performed in two phases, an elimination phase followed by a propagation phase. The elimination phase processes the program intervals in a bottom up (innermost to outermost) traversal. During each step of the elimination phase, data flow information is summarized for inner ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....rationale of these approaches is to avoid computing irrelevant intermediate results, while still performing a global analysis. Reducing the cost of interprocedural data flow analyses can also be achieved by demand driven techniques, such as those presented in [33] and [69] Incremental analysis [15, 59, 75] addresses the problem of avoiding unnecessary recomputations of data flow solutions in case of local program changes; but it requires an initial exhaustive solution. Another solution to reduce the cost of interprocedural analyses is to perform 5 Array region analyses collect information about ....

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems, 12(3):341--395, July 1990.

....aliasing, unlike reference parameter aliasing, not only can the calling procedure affect the aliasing of the called procedure, but the called procedure can also affect the aliasing of the calling procedure. The conventional methods for side effect analysis [Banning 1979; Cooper and Kennedy 1988; Burke 1990] decompose the computation into separate direct sideeffect and alias analyses. Aliasing information is factored into direct side effects after the latter has been computed. In the presence of pointers, it can be incorrect to perform side effect analysis without using alias information because ....

Burke, M. 1990. An interval-based approach to exhaustive and incremental interprocedural data-flow analysis. ACM Transactions on Programming Languages and Systems 12, 3 (July), 341--395.

No context found.

Burke, M. An interval-based approach to exhaustive and incremental interprocedural analysis. Tech. Rep. RC 12702, IBM Research Center, Yorktown Heights, NY, Sept. 1987.

No context found.

M. Burke. An interval-based approach to exhaustive and incremental interprocedural data- ow analysis. ACM Transactions on Programming Languages and Systems, 12(3), July 1990. 182

First 50 documents  Next 50

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