D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In SIGPLAN Conference on Programming Languages Design and Implementation, pages 47--56, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....semantics to capture the useful properties of control flow graphs and their statements. On the other hand, they improve on classical MFP analyses because they use some form of symbolic computation to analyze array subscripts more precisely. The pioneering work was done by Callahan and Kennedy [9, 8] who explicitly defined their analysis as a distributive data flow problem. Kallis and Klappholz ware perhaps the first to propose a RD analysis in the face of array references with lexically different subscripts [22] In the sequel, we describe more recent related work by Gu, Li and Lee [18, 19] ....

D. Callahan. The program summary graph and flow-sensitive interprocedural d ata flow analysis. In SIGPLAN PLDI, pages 47--56, Atlanta, Ga, June 1988. ACM.

....not aware of them at the time. Our work was more influenced by Kastens s algorithm for building a collection of cooperating finite state machines for evaluating derivation trees of attribute grammars [24] see below) The two other papers in the session at PLDI 88 in which our paper was presented [8, 12] actually foreshadowed a major direction that our work was to take subsequently: Callahan presented a context sensitive algorithm for a certain kind of dataflow analysis problem [8] Cooper and Kennedy presented a graph reachability algorithm for finding procedures MayMod and MayUse sets (which ....

.... grammars [24] see below) The two other papers in the session at PLDI 88 in which our paper was presented [8, 12] actually foreshadowed a major direction that our work was to take subsequently: Callahan presented a context sensitive algorithm for a certain kind of dataflow analysis problem [8]; Cooper and Kennedy presented a graph reachability algorithm for finding procedures MayMod and MayUse sets (which summarize possible side effects of procedure calls on global variables) 12] Later work by Horwitz, Reps, and collaborators showed how many dataflow analysis problems similar to the ....

[Article contains additional citation context not shown here]

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Conf. on Prog. Lang. Design and Impl., pages 47--56, New York, NY, 1988. ACM Press.

....time and precision of the results. Several algorithms, with di erent sensitivity to control ow and calling context, have been developed to obtain accurate and ecient results on reaching de nitions. While traditionally ow sensitive analyses received great attention from the research community [7,9,23,32], recently ow insensitive analyses have been investigated for their eciency, and the trade o between time complexity and accuracy has been evaluated [25] with regard to the points to analysis. In [17] the problem of handling the e ects of di erent calls to the same procedure has been termed the ....

D. Callahan, \The Program Summary Graph and Flow-sensitive Interprocedural Data Flow Analysis", Proc. of the ACM SIGPLAN'88 Conf. on Programming Language Design and Implementation, pp. 47-56, Atlanta, Georgia, June 22-24, 1988.

....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. ....

....the logical data flow between procedures from the physical data flow (or data dependence) encoded in the system dependence graph. These algorithms will give the flat data flow design of a program. The algorithms may be a variation of the algorithms for computing interprocedural summary information [7, 11, 19]. 2. Develop algorithms for identifying the type of data or name of the variable that flows between procedures and to create the data dictionary using information. 3. Develop algorithms to create a hierarchical data flow design by integrating the flat data flow design, the data dictionary, ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pages 47--55, June 1988.

.... R0, R1 and live at exit = R0 . R0 is in the live at entry and live atexit sets because a return path from P 2 leads to a use of R0 in P 1 . 3 Interprocedural Dataflow To generate the interprocedural dataflow sets described above, Spike uses a Program Summary Graph (PSG) similar to Callahan s [Callahan88] and a two phase approach [Srivastava93] that computes the call used, calldefined, and call killed sets for each routine in the first phase, and then computes the live on entry and live onexit sets in the second phase. This section first describes the construction of the program summary graph, and ....

....of the program summary graph, and then describes the dataflow phases. 3.1 Program Summary Graph The program summary graph is a compact representation of a program s intraprocedural control flow, composed of nodes and directed edges. Although it is conceptually similar to the PSG proposed in [Callahan88], the PSG used by Spike differs significantly in its construction and in its encoded information. Each PSG node represents a location in the program for which dataflow information is being collected. Each node records the MAY USE, MAYDEF, and MUST DEF sets for the program location represented by ....

[Article contains additional citation context not shown here]

D. Callahan. "The program summary graph and flow-sensitive interprocedural data flow analysis," in Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation `88, pp 47-56, June 1988.

....Partial Program Summary Graph (PPSG) Finally, data flow propagation on the PPSG is done to improve the precision of the call graph using reaching types information. 3. 1 Program Summary Graph We use the interprocedural representation Program Summary Graph (PSG) initially proposed by Callahan [7], for presenting our demand driven call graph analysis technique. We initially give the original definition of PSG and then describe several extensions of PSG that we use for our purpose. A program summary graph is a representation of the complete program that is much concise as compared to the ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, Atlanta, GA, June 1988. 18

....belongs to the value attribute of a variable definition is called a substitutor of the variable definition. Each substitutor is characterized by its status: d definite substitutor or p possible substitutor. The problem of finding the substitutors is known as the pointer aliasing problem [1, 2, 7, 12, 11]. This problem can be solved by using the set of abstract variables as a memory model (store based approach [4] Another approach called the path access based approach [1, 12, 11] is more widely used. The value of a variable of the scalar type considered as the attribute of the variable ....

....or p possible substitutor. The problem of finding the substitutors is known as the pointer aliasing problem [1, 2, 7, 12, 11] This problem can be solved by using the set of abstract variables as a memory model (store based approach [4] Another approach called the path access based approach [1, 12, 11] is more widely used. The value of a variable of the scalar type considered as the attribute of the variable definition is approximated by the list of ranges of possible scalar values. The problem of the approximation of scalar type variables is known as the problem of the value range propagation ....

D. Callahan. The program summary graph and flowsensitive interprocedural data flow analysis. Proc. ACM SIGPLAN'88 Conf. Conf. on Prog. Lang. Design and Implem., Atlanta, (2), 1999.

....a demand driven basis as well. 3 Interprocedural Flow Graph We use the interprocedural representation Interprocedural Flow Graph (IFG) initially proposed by Harrold and Soffa [13] This representation is also closely based upon the representation Program Summary Graph (PSG) proposed by Callahan [5]. We initially give the original definition of IFG and then describe several extensions of IFG that we use for our purpose. A Interprocedural Flow Graph (IFG) is a representation of the complete program that is much concise as compared to the Myers Supergraph or Interprocedural Control Flow ....

D. Callahan. The program summary graph and flowsensitive interprocedural data flow analysis. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, Atlanta, GA, June 1988.

.... compilers, optimization Additional Keywords and Phrases: inline substitution, interprocedural analysis, interprocedural optimization 1 Introduction In recent years, many articles dealing with issues of interprocedural analysis and interprocedural optimization have appeared in the literature [1, 2, 5, 6, 7, 10, 12, 14, 17, 18, 19, 20, 21]. Several of these articles have attempted to assess the practical value of interprocedural data flow information or of specific cross procedural transformations. Ganapathi and Richardson point out that inline substitution can be viewed as an upper limit on the improvement available through use of ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, SIGPLAN Notices 23(7), pages 47--56. ACM, July 1988.

....It must use the results of this analysis to transform the program into a form where it is more amenable to efficient execution on the target system. Interprocedural analysis. Algorithms for performing data flow analysis across whole programs are both readily available and well understood [5, 7, 8, 10]. These techniques are beginning to appear in commercial systems [25] Perhaps less well appreciated are the limitations of this kind of analysis, the role that it can play in code optimization, and the rational consequences of that role. Interprocedural data flow analysis is a technique for ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, SIGPLAN Notices 23(7), pages 47--56. ACM, July 1988.

....either indicates convergence or provides a better approximation of the read write sets. Our algorithm can be easily extended to use a worklist, as done in [Landi and Ryder 1992; Hall and Kennedy 1992] It can also be extended to build the Interprocedural Control Flow Graph (ICFG) Myers 1981; Callahan 1988; Harrold and Soffa 1994; Landi and Ryder 1992] instead of the PCG. 11.5 Alias Representation The compact representation, introduced in [Choi et al. 1993] is highly similar to the points to representation of Emami et al. 1994] The only difference between the representations is that the ....

Callahan, D. 1988. The program summary graph and flow-sensitive interprocedural data flow analysis. In SIGPLAN '88 Conference on Programming Language Design and Implementation. 47--56. SIGPLAN Notices, 23(7).

....be done either at the interprocedural level, or even at the intraprocedural level. In this last case, the size of the representation of each procedure is reduced. Several sparse interprocedural representations have been designed for particular classes of problems, such as the program summary graph [19], the system dependence graph [34, 10] Intraprocedural sparse representations include the ssa form [3, 32, 76] and the sparse data flow evaluation graph [24] The unified interprocedural graph [48] provides a demand driven unified representation which combines the advantages of the sparse ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data-flow analysis. International Conference on Programming Language Design and Implementation, ACM SIGPLAN Notices, 23(7):47--56, July 1988.

....Related Work and Conclusions The core of our algorithm for closing an open system is a dataflow analysis of C or C like procedures. The dataflow analysis is phrased as a graph reachability problem. This is a common approach to dataflow problems that our algorithm shares with many others, such as [Cal88, CK88, Kou77] to name but a few. In particular, we use standard techniques for computing define use dependencies, such as [ASU86, FOW87, MR90] These techniques rely on a (conservative) solution to the aliasing problem. Examples of alias analyses include [CWZ90, Deu94, Lan91, Ruf95, SRW96] to ....

D. Callahan. The program summary graph and flowsensitive interprocedural data flow analysis. In Proceedings of the ACM '88 Conference on Programming Lanugage Design and Implementation, pages 47--56, Atlanta, GE, USA, June 1988. ACM Press.

.... program representations, and adds new information, to provide an integrated representation for maintenance tasks [27] Constructed only for specified groups of procedures on demand, this single intermediate representation combines relationships found in a call graph, a program summary graph [11], an interprocedural flow graph [31] and a system dependence graph [30] As the UIG is based on a call graph, the program s syntax is not present in this representation. Data flow dependencies are explicitly represented, which implies that the UIG could be quite large and costly to compute. The ....

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 47--56, 1988.

....needed for data dependency analysis which is a precondition for parallelization. The data flow analysis relies on iterative data flow algorithms described in [2] Liveness information has to computed as well. Data flow analysis is performed interprocedurally applying the approach proposed in [8] to get more precise data flow informations. The parallelization and generation of wide instruction word code will be achieved by applying the transformations defined within the percolation schedul core transformations control strategies software pipelining code generation VLIW architecture ....

Callahan, D.: The Program Summary Graph and Flow--sensitive Interprocedural Data Flow Analysis. Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, SIGPLAN Notices, (1988) 47--56, Atlanta, Georgia

....study of four major types of function pointer manipulation found in the SPEC benchmarks. Finally, conclusions are given in Section 5. 2 Background Many algorithms have been designed to construct the complete call graph for languages supporting limited forms of function or procedural variables [7, 8, 9, 19, 20, 21]. The basic idea is to propagate the contents of parameters along the existing call graph. For example, in the BoundTo analysis proposed by Hall and Kennedy [9] if a procedure variable passed as a parameter is bound to a new procedure, the new procedure will be included in the call graph. ....

D. Callahan, "The program summary graph and flow-sensitive interprocedural data flow analysis," in Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, pp. 47--55, June 1988. 19

....to a flow sensitive interprocedural analysis. The FCFG can support a flow sensitive interprocedural analysis that propagates method summaries in the same manner as in the traditional CFG, or it can be used to build an interprocedural FCFG (IFCFG) in the spirit of the interprocedural CFG [16, 19, 4, 14, 12]. In building the IFCFG, an interprocedural path must exist from a PEI with an exit edge to any handlers in calling methods that might catch the exception. A spectrum of precision exists in creating this path. A simple approach would be to create edges from the PEI to the exit node in the called ....

....traditional control flow graph to enable both intraprocedural and interprocedural analysis of Java, Modula 3 [17] and Cecil [5] programs. Chatterjee et al. 6] have developed an extension of Landi and Ryder s conditional points to [14] that can precisely model exceptional control flow in the ICFG [16, 19, 4, 14, 12]. Sinha and Harrold [20] detail the subtleties of correctly capturing the semantics of Java s try catch finally structure in a traditional CFG representation. The Jex tool of Robillard and Murphy [18] constructs method level summaries of a program s exception structure. By examining these ....

David Callahan. The program summary graph and flowsensitive interprocedural data flow analysis. In SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 47--56, July 1988. SIGPLAN Notices, 23(7).

....following notation: v 1 cd v 2 We note that every component of P that is not subordinate to any control predicate is control dependent on the entry node. As an example, consider the program fragment used to calculate the factorial of the number 4 shown in Table 1. The execution of statements [6] and [7] is dependent on the control predicate at statement [5] According to the definition of control dependence, we can conclude that statements [6] and [7] are control dependent on statement [5] main( 1] int fact; 2] int n; 3] n = 4; 4] fact = 1; 5] while (n = 0) 6] fact = ....

....node. As an example, consider the program fragment used to calculate the factorial of the number 4 shown in Table 1. The execution of statements [6] and [7] is dependent on the control predicate at statement [5] According to the definition of control dependence, we can conclude that statements [6] and [7] are control dependent on statement [5] main( 1] int fact; 2] int n; 3] n = 4; 4] fact = 1; 5] while (n = 0) 6] fact = fact n; 7] n = n 1; Table 1. A sample program. Data flow edge: If data propagate from v 1 to v 2 , then we say that v 2 is data flow dependent ....

[Article contains additional citation context not shown here]

D. Callahan. "The Program Summary Graph and Flow-sensitive Interprocedural Data Flow Analysis", In Proceedings of the SIGPLAN 1988 Conference on Programming Language Design and Implementation, Atlanta Georgia, June 22-24, 1988.

No context found.

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In SIGPLAN Conference on Programming Languages Design and Implementation, pages 47--56, 1988.

No context found.

Callahan, D., "The program summary graph and flow-sensitive interprocedural data flow analysis," Proceedings of the ACM SIGPLAN 88 Conference on Programming Language Design and Implementation, (Atlanta, GA, June 22-24, 1988), ACM SIGPLAN Notices 23(7) pp. 47-56 (July 1988).

No context found.

Callahan, D., "The program summary graph and flow-sensitive interprocedural data flow analysis," Proc. of the ACM SIGPLAN 88 Conf. on Prog. Lang. Design and Implementation, (Atlanta, GA, June 22-24, 1988), SIGPLAN Not. 23(7) pp. 47-56 (July 1988).

No context found.

David Callahan. The Program Summary Graph and Flow-Sensitive Interprocedural Data Flow Analysis. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 47--56, June 1988..

No context found.

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In SIGPLAN Conference on Programming Languages Design and Implementation, pages 47--56, 1988. 51

No context found.

Callahan88. Callahan, D., The program summary graph and flow-sensitive interprocedural data flow analysis, Proceedings of the ACM SIGPLAN 88 Conference on Programming Language Design and Implementation, (Atlanta, GA, June 22-24, 1988), ACM SIGPLAN Notices 23(7) pp. 47-56 (July 1988).

No context found.

D. Callahan. The program summary graph and flow-sensitive interprocedural data flow analysis. In SIGPLAN Conf. on Prog. Lang. Design and Imple. June 1988.

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