1. Interprocedural Constant Propagation
David Callahan
Keith D. Cooper
Ken Kennedy
Linda Torczon
Department of Computer Science+
Rice University
Houston, Texas
Abstract
In a compiling system that attempts to improve code for a whole program by optimizing across pro-
cedures, the compiler can generate better code for a specific procedure if it knows which variables will
have constant values, and what those values will be, when the procedure is invoked. This paper
presents a general algorithm for determining for each procedure in a given program the set of inputs
that will have known constant values at run time. The precision of the answers provided by this
method are dependent on the precision of the local analysis of individual procedures in the program.
Since the algorithm is intended for use in a sophisticated software development environment in which
local analysis would be provided by the source editor, the quality of the answers will depend on the
amount of work the editor performs. Several reasonable strategies for local analysis with different lev-
els of complexity and precision are suggested and the results of a prototype implementation in a vec-
torizing Fortran compiler are presented.
about data usage and creation among the procedures
1. Introduction that form a single program, so that the compiler can
Fortran programmers have learned to expect take advantage of contextual information to generate
optimizing compilers that generate excellent code for a better code for any single procedure. An important
single procedure. Twenty-five years of development has interprocedural data flow analysis problem is the deter-
led to a well-understood collection of principles for build- mination of which parameters’ to a given procedure will
ing optimizing compilers and almost every commercially be constant at run time. Based on this information, a
available computer system now offers one. One problem compiler could perform a number of useful optimizations
remains, however. The quality of the code produced by that are unavailable to it in current compilation
a good Fortran compiler declines considerably in the schemes. For example, many subroutines in the LINPACK
presence of calls to independently compiled procedures. library [DBMS 791 have a parameter to indicate the
The main reason for this is that the compiler must make stride of indexing for some array. In the typical program
worst case assumptions about what happens on the side constructed from LINPACK, this stride is passed the
of the interface that it cannot see. For example, when integer constant “1”. In the absence of better informa-
compiling the called procedure, the standard linkage tion, the compiler must assume that the parameter could
convention requires that all the registers be saved and take on any value, precluding the application of many
restored, even though many of them may not be in use optimizations. In particular, the value “0” would pre-
at the point of call. clude vectorization of array operations within the pro
Intetprocedural data flow analysis attempts to cedure and a non-constant value would preclude loop
overcome this problem by propagating information unrolling, both of which have proven effective in improv-
ing performance of programs constructed from LINPACK
Permission to copy without fee all or part of this material is granted provided [Dong 801.
that the copies are not made or distributed for direct commercial advantage.
the ACM copyright notice and the title of the publication and its date appear.
and notice is given that copying is by permission of the Association for
Computing Machinery. To copy otherwise, or to republish. requites a fee and/
t This research has been supported by the National Sci-
or specific permission. ence Foundation through grants MCS 81-21844 and MCS 83-
03638 and by IBM Corporation.
‘Here we extend the term parameter to cover global or
@ 1986 ACM O-89791-197-O/86/0600-0152 75C imported variables.
152

2. Constant propagation is a code improvement tech- interprocedural data flow information is the responsibil-
nique in which the compiler reasons about the values ity of the program compiler. Most of the required inter-
that variables may assume at run time. If the compiler procedural information is developed by solving data flow
is able to establish that a variable will always have a analysis problems on the program’s call graph. Since the
known constant value at a particular use point it may call graph of a program is likely to be large, it is impor-
replace an occurrence of that variable by an occurrence tant for the program compiler to employ efficient algo-
of the constant itself. Whenever all the inputs to an rithms for solving these data flow problems. Previously,
operation are replaced by known constant values, the Cooper and Kennedy have reported nearly-linear algo-
operation may be performed at compile time and the rithms for the determination of side effects [CoKe 841
constant result further propagated to other uses. When and potential aliases [Coop 851.
performed in a systematic way, constant propagation In this paper, we present a scheme for efficiently
can lead to the evaluation at compile time of many determining which variables have known constant values
operations that might be repeatedly performed at run on invocation of the various procedures in a given pro-
time. This can significantly improve the performance of gram. Of necessity, our method is approximate. Kam
the compiled program. and Ullman have shown that a precise solution to the
Techniques for constant propagation within a sin- simpler problem of intraprocedural constant propagation
gle procedure have been widely discussed in the litera- is not computable [KaUI 77). Even the approximate
ture ]Kild 73, Kenn 78, Kenn 81, WeZa 85). However, problem commonly solved by compilers within a single
these techniques have not been extended to propagate procedure is intractable in an interprocedural setting
constants across procedure calls2 for reasons of practical- because it has the property of flow sensitivity (Myer 811.
ity. In order to compute which variables are constant at Therefore, we present a collection of methods that all
every invocation of a given procedure, the system must use the same algorithm for propagating constants across
have knowledge of the behavior of every procedure in the the call graph but differ in the precision of the informa-
program. In a traditional separate compilation system, tion used to model the behavior of individual procedures.
the compiler doesn’t even know which procedures the This collection of algorithms clearly exhibits the tradeoff
program includes until the link editing step immediately between complexity of local analysis by the source editor
prior to execution. Even if the compiler had this and the precision of the approximate sets of constants -
knowledge, without a database similar to those found in more effort by the editor leads to finding a larger set of
a programming environment, it would need to examine variables with known constant values.
every procedure in the program in order to compile just The discussion begins in Section 2 with a presenta-
one of them. This appears to be prohibitiveIy expensive. tion of a very precise method based on inline substitu-
In an attempt to address these problems, the IRn tion and a discussion of the drawbacks of this approach.
project at Rice University has been developing a pro- The algorithm we propose to use in the IRn environment
gramming environment for Fortran that supports the is presented in Section 3. It is based on an efficient algo-
development, compilation and optimization of whole pro- rithm for constant propagation in a single procedure due
grams [HoKe 85, CoKT 85, CoKT 861. A central goal of to Reif and Lewis [ReLe 821 as adapted by Wegman and
this project is to experiment with the systematic Zadeck (WeZa 851. Our algorithm models the body of a
development of interprocedural data flow information. procedure with functions that describe the values of
In IR’, the eoutce editor provides local information about variables at a call site in terms of the values of variables
the behavior of individual subroutines and a program on entry to the procedure containing the call. Section 4
composition editor records which subroutines comprise describes several methods for defining these functions
the program. Once local information is available and and contrasts the completeness of the resulting constant
the program composition is known, the computation of sets. Section 5 describes our experience with an actual
implementation of interprocedural constant propagation
2A notable exception is the paper by Wegman and Za- in a Fortran vectorizer. Finally, conclusions and future
deck (WeZa 851, which describes a single-procedure algorithm research are discussed in Section 6.
that can be used to evaluate the effectiveness of inline expan-
sion of a called procedure. The technique propagates the
known constants at a single call site into the called procedure
to determine the size of the code that would result after inline
expansion and useless code elimination. This approach does
not extend naturally to handle procedures that are not ex-
panded inline and may be called from more than one site.
153

3. 2. Mine Substitution
Perhaps the most obvious way to solve the prob-
lem is to convert the program into one large procedure procedure main;
using systematic inline substitution and employ an write 1000, 1000,2000,2000;
efficient single-procedure method such as the Reif-Lewis end;
algorithm [ReLe 821 or the Wegman-Zadeck algorithm
[WeZa 851. Recursive procedures can be handled in this Figure 2. After inline substitution.
scheme by introducing an explicit stack, combined with
unrolling. This approach is very effective at propagating
constants because, in effect, each call site has its own
Second, systematic use of inline expansion makes the
private copy of the called procedure. Hence, constant
program difficult to maintain. After each change to a
propagation is not inhibited by having to merge con-
single procedure, the system must either re-expand the
stant sets from several call sites to produce information
program or attempt to recreate the change in the
for a procedure that is invoked from more than one loca-
expanded, optimized program, a process that is likely to
tion. Furthermore, inline substitution makes parameter
be very expensive. Therefore, we seek a method that
aliasing explicit in the program, permitting the analysis
performs constant propagation on the whole program
to be even more precise. When applied to the example
while keeping the individual procedures separate. Furth-
in Figure 1, the method based on inline substitution will
ermore, that method should have an efficiency that is
yield the program in Figure 2.
proportional to the aggregate size of all the code in the
In spite of its effectiveness, we reject this tech- program. In return for achieving these goals, we are wil-
nique for practical use on several grounds. First, the ling to sacrifice some constant propagation effectiveness.
growth in the program’s code size after substitution is
In spite of its drawbacks, inline substitution
potentially exponential [Sche 771. Since the performance
deserves study because it provides us with a standard by
of the best algorithms for single-procedure constant pro-
which to measure the effectiveness of other techniques.
pagation is roughly linear in the size of the procedure,
Furthermore, it can be extremely valuable as an optimi-
the overall cost of constant propagation is potentially
zation technique if used in a controlled way [Ball 791. In
exponential in the size of the unexpanded program.
fact, interprocedural constant propagation can provide
the information required to efficiently determine when
inline substitution can be profitably employed [Coop 88,
procedure main; WeZa 851. In the next section we present the general
0: call j0e(lO,lOO,lOOO); strategy used in the IR’ programming environment to
end; propagate constants across procedure boundaries
without using inline expansion.
procedure jotfi, j, k);
1=2*k;
if (j-100) then m = lO*j else m = i; 3. General Approach
j3: call ralph(l, m, k); The goal of interprocedural constant propagation
o-m*2;
is to annotate each procedure in the program with a set
q- 2;
7: call ralpk(o, q, k); CONSTANTS(p) of <name,vahLe> pairs. A pair <z,u> E
write q, m, 0, 1; CONSTANTS(~) indicates that variable z has value v at
end; every call site that invokes p. This set approximates
reality; every pair in CONSTANTS(~) denotes a run-time
procedure ralph(a, b, c); constant, but not all run-time constants can be found.
b=a*c/2000;
For the purpose of computing CONSTANTS(~) we
end;
formulate the problem in a lattice theoretic framework.
Figure 1. An example problem With each entry point p we associate a function Vu1
that maps formal parameters to elements of the usual
constant propagation lattice L. Each element of L is one
of three types:
154

4. . a lattice top element T,
. a lattice bottom element 1, or
. a constant value c procedure PropagateConstant;
The structure of this lattice is defined by the following var worklist : set;
list of rules for the lattice meet operation pI: begin
{ Initialize }
1) TA a - a for any lattice element a
for each procedure p in the program do
2) 1 A a = 1 for any lattice element a for each parameter z to p do
3) CA c - c for any constant c vur(z) :- T;
4) clA c2-1 if cl+ c2 for each call site 8 in the program do
for each formal parameter y
Figure 3 depicts the constant propagation lattice graphi- that receives a value at s do
calfy. While it is an infinite lattice, it has bounded V4Y) := vayY)AJJ;
depth. In particular, if a variable is modified by assign- worklist := 0;
ing it a new value computed by taking the meet of its for each procedure p in the program do
old value and some other lattice element, its value can for each parameter z to p do
be reduced at most twice. worklist := worklist u {z};
For any formal parameter z, let Vu(z) represent { Iterate }
the best current approximation to the value of z on while worklist + 0 do begin
entry to the procedure. After the analysis is complete, if let y be an arbitrary parameter in worklist;
worklist :- worklist - { y};
Vul(z)-1, the parameter is known to be non-constant; if
let p be the procedure containing y;
Va’dyz)-c, the parameter has the constant value c. The
value T is used as an initial approximation for all { Update worklist )
for each call site s E p and parameter z
parameters; a parameter retains that value only if the
such that y E support(J,3 do begin
procedure containing it is never called. Once we have 0ldVal :- Val( z);
computed VIZ(Z) for every parameter z of procedure p, Val(z) := Val(z)r J:;
CONSTANTS(P)is simply the set of parameters for which if Val(z)<oldVal then
Val is equal to some constant value. worklist :- worklist IJ {z};
end
To compute the Vu1 sets, we associate with each
end
end
Figure 4. General algorithm
call site s in a given procedure p a jump function’ J,
that gives the value of each parameter at s as a function
of the formal parameters of the procedure p”. J, is actu-
ci-1 Cl G+1 .. ally a vector of functions, one for each formal parameter
of the procedure invoked at the call site. For each for-
mal parameter y of the procedure called at 8, the com-
ponent function J,’ computes the best approximation
1 within the lattice L to the value passed to y at call site
s, given the values passed to formal parameters of p.
The support of the function J,’ is the exact set of formal
Figure 3. The constant propagation lattice.
3The term jump function originated with John Cocke
and is used here for historical reasons.
‘For the purposes of this discussion, ignore the issue of
global variables used as parameters. These can be treated as
an extended set of parameters.
155

5. parameters of p that are used in the computation of J,Y SUPPO~ Jbl)= ia
Given these definitions, the interprocedural con- . For any parameter z at call site s that is deter-
stant propagation problem can be solved using an analo- minable at compile time but not a constant. J: is
gue of the Wegman-Zadeck method for constant propa- a function of parameters to the calling procedure
gation in a single procedure [WeZa 851. The interpro- and local constants of the calling procedure. In
cedural algorithm, shown in Figure 4, assumes that each this case, support( Jf) is non-empty.
parameter used in the program has a unique name, so Taken together, these principles gives rise to a range of
the procedure to which it is a parameter can be uniquely strategies for constant propagation. The boundary
determined from the parameter name. The algorithm between these three classes of values depends on the
uses a worklist of parameters to be processed. It is sophistication of the techniques used in the source editor
guaranteed to converge because the lattice is of finite to determine jump functions. If the complexity of com-
depth and a parameter is only added to the worklist puting a particular jump function exceeds the capabili-
when its value has been reduced. Since the value of any ties of the editor, it can simply give up and assign
parameter can be reduced at most twice, each procedure J,’ = 1. Torczon discusses three strategies of different
parameter can appear on the worklist at most two times. complexity for developing jump functions [Tort 851 -
If eost(J:) is the cost of evaluating J,‘, the total one that only finds jump functions that are constant or
amount of work done by the computation is proportional bottom, one that also discovers jump functions that pass
to a parameter through to a call site without change, and a
third that employs a sophisticated symbolic interpreta-
s I tion algorithm such as the one proposed by Reif and
Lewis [ReLe 821. We describe each of these in the follow-
where s ranges over all call sites in the program and z
ing sections.
ranges over all formal parameters that are bound by the
call at 8. This bound is based on the observation that
Jf is evaluated each time some parameter in support( J:) 4.1. All or Nothing
is reduced in value. Because of the structure of the lat- A particularly easy to implement technique would
tice, a parameter can be reduced in value at most twice. have the source editor employ a single-procedure con-
If the cost of evaluating each J,’ is bounded by a con- stant propagation technique, such as the Wegman-
stant, implying that the size of the support is also
bounded by a constant, the cost is proportional to the
sum over each edge in the call graph of the number of
parameters passed along that edge. procedure main;
The tricky part of this method is the construction 0: call j0~10,100,1000);
of the jump functions J,. The next section describes end;
three methods for implementing them. procedure joe(i, j, k);
192ooo;
m- 1000;
4. Jump Functions
B: call ralph(l, m, k);
In developing algorithms for the construction of o-m*2;
jump functions, we should keep the following principles q-2;
in mind. 7: C811 talph(0, q, k);
write q, m, 0, 1;
. For any parameter z at a call site s that can be
end;
determined to be constant by inspection of the
source of the procedure containing s, set JJ=c procedure ralph(a, b, c);
where c is the known constant value. This implies b=a#c/2000;
that support( Jf) = 0. end;
. For any parameter z at call site s that cannot be Figure 5. After all-or-nothing analysis.
determined as a function of input parameters to
the procedure containing s, set J: to be 1. For
example, z might be passed a value that is read in
from an external medium. Again, this implies that
156

6. Zadeck algorithm to determine which variables are con- 1) Make a fresh copy of the procedure containing s.
stant at each call site, under the assumption that none Replace all input statements by an assignment of
‘4
of the parameters to the routine containing the cali site 1 to each of the variables read.
are constant. Then each jump function J,” is set to a con-
stant value if the analysis determines that z must be 3) Replace each call site other than s by an assign-
constant at 8 and to 1 otherwise. This approach would ment of 1 to each of the actual parameters.
find constants that can be propagated over a single call. 4 Eliminate all statements that cannot affect the
It would miss all constants that must be propagated value of the actual parameter passed to z at s
completely through an intermediate procedure. using a traditional dead code eliminator based on
DEF-USE chains such as the one described by Ken-
In the example of Figure 1,this method would dis-
cover that i, j and k are constant on entry to joe and nedy [Kenn 811.
that b is constant at call site 7 although not at call site In practice, we would use a much more efficient tech-
p. Because procedure joe is analyzed to produce Jb nique for constructing these jump functions, such an an
before the interprocedural propagation takes place, it adaptation of the Reif and Lewis symbolic interpretation
cannot discover that k is constant at call site ,8, even algorithm [ReLe 821.
though it is directly passed from the entry to j3. The Using this technique on the example in Figure 1,
overall effect of the propagated information after optimi-
we would get the following jump functions.
zation is shown in Figure 5.
Jj - 2 *k
4.2. Pass Through
Jb - if j-100 then 1000 else i fi
Jb - k
One way to enhance the all-or-nothing technique
is to recognize those situations when a variable is J; =I
directly passed through a procedure to a call site. This J; = 2
case arises in our example because k is passed by joe to Jr, -1
call site j3. In other words, we would determine that
When the algorithm is applied with these jump function,
Jj = k. it will discover that a is passed the constant 2000 and c
This is an easy extension to implement because the is passed the constant 1000 at call site B. Unfortunately,
determination can be based on DEF-USE chains [AhUI 77, the information at 7 is not as good. Both J$ and J; are
Kenn 781, which are required by the single-procedure unknown because of the possible side effects at call site
constant propagation methods. If we trace back from a 8. The problem is that we know nothing about the com-
call site 8 to all definition points for variable y, passed putations performed by ralph . The next section
to x at s, and find that the only such point is the pro- discusses the possibility of using information from the
cedure entry, we may safely set J+y. solution of other interprocedural data flow problems to
sharpen our analysis.
This enhancement is only slightly more difficult to
implement than the all-or-nothing method, yet it finds
constants that are passed through several procedures, a 4.4. Side Effect Information
common practice in code based upon libraries like LIN- A particularly interesting aspect of the computa-
PACK. In our example, this method would discover that
tion of jump functions is their dependence on the solu-
k was constant at call site p but would set k to 1 at call tion of other interprocedural data flow problems. Sup-
site 7 because the single-procedure analysis must assume
pose the procedure p contains a call to another pro-
that ralph could change k as a side effect at call site 8. cedure q on every path through p to call site s. How
We will discuss this problem shortly. does this affect the jump function for s? In the absence
of better information, we must assume that every formal
4.3. Symbolic Interpretation parameter to q and every global variable is changed
upon return from q. Hence, any jump function that
Suppose we take a much more aggressive approach depends upon one of those variables must be set to 1.
and build jump functions by symbolic interpretation. A
simple way to view the construction of a symbolic J: is However, we can use the results of interprocedural
as follows. side effect analysis to obtain better information. Sup-
pose we can formulate jump functions to conditionally
157

7. depend on whether certain variables may be modified by It is important to note that the MOD sets for the
some procedure invocation. For example, suppose the context program are likely to change between the time
value passed to a parameter at call site s depends on the source editor creates the jump function and the time
whether or not another variable is modified at call site t. the constant propagation problem is solved. Care must
be taken to ensure that the constant propagation phase
Jl=if CZEMOD(~) then 1 else a+b fi
uses the current value of MOD rather than the old value.
where MOD(t) is the set of variables that may be If the compiling system performs side effect analysis
modified as a side effect of invoking the procedure called before constant propagation, up-to-date information
at t. In the IRn environment, the program compiler about side effects will be available when the jump func-
develops a complete collection of MOD sets for the pro- tions are evaluated. Without the ability to build jump
gram based on information gathered by the source editor functions that are conditional on MOD information in this
and the program composition editor [CoKe 84, CoKT 85, way, the editor would be forced to make J+J~d.
CoKT 861. This information could be very useful for
interprocedural constant propagation. In our example,
4.5. Returned Constants
the jump functions for a and 6 at 7 become:
J; - if mEMOD@) then 1 The inability of the constant propagation algo-
else if j-100 then 2ooO else 2*i fi rithm to determine the value of the parameter returned
by Ralph through formal parameter 6 illustrates a
J; - if ~EMoD(~) then 1 else k fi
further problem. This situation could be improved by
This would lead to the discovery that c was constant at creating the analogue of jump functions for values
7 and hence c-1060 on entry to ralph In Figure 6, we returned by a procedure call. Let R; be a function,
show the code resulting from these improvements. The defined over the same lattice as the jump functions, that
assignment in ralph has been simplified and, since we provides a value for the output parameter z of procedure
know that parameters a and c to ralph are not modified, p in terms of the input parameters to p. We shall call
it is safe to propagate constant values into the this a return jump function. A method based on symbolic
corresponding actual parameter positions at call sites p interpretation would discover that
and 7. Notice also that we can eliminate all references
to 1 in joe by propagating its constant value into the R,b,,,* - a * c/2000.
write statement. If we then permitted J: for example 1 to be redefined as
J; = if mEMoD th en R!~,A(JB,J$,J$)X~
else if j-100 then 2000 else 2 *i fi
procedure main; the technique would discover that a is passed the con-
a: call j0e(10,100,1000); stant value 2000 at 7 as well as ,B. Hence a-2000 on
end;
procedure joefi, j, k);
m- 1000; procedure main;
8: call raIph(2000, m, 1000);
cv: call joe(lO,lOO,lOOO);
o-m*2;
end;
q- 2;
7: call ralph(0, q, 1000); procedure joe(i, j, k);
write q, m, 0, 2000; write 1000, 1000,2000,2000;
end; end;
procedure ralph(a, b, c); procedure ralph(a, b, c);
b - a/2; b-1000;
end; end;
Figure 8. Using symbolic jump functions. Figure 7. Using return jump functions.
158

8. entry to talph and it always sets b-1000 on exit. Figure The expressions also contain two types of
7 depicts the example program after each individual rou- “dummy” operator nodes. The first type represents a
tine has been optimized in the light of interprocedural point where the “value” computed by the subtree of the
constants and return jump functions. Since the values of dummy node was passed to a subroutine call. It consists
q,wa,o and 1 have been substituted in the write state- of the index of an edge in the call graph representing
ment, all other statements in joe can be eliminated. that call site and an integer indicating which parameter
This result is pleasingly close to the one for inline substi- position it held. The presence of such an operator indi-
tution. cates that the interprocedural MOD information must be
It may occur to the reader that return jump func- interrogated to determine whether that value is modified
tions might be defined in terms of other return jump as a side effect of the call.
functions. There is no reason that this should not per- The second type of dummy operator indicates that
mitted as long as the system is careful to insure against a parameter or COMMON variable was used in construct-
infinite invocation loops. In the implementation dis- ing the expression tree. Expressions containing this
cussed in the next section, we permit an arbitrary use of operator can be “invalidated” (or made nonconstant) if
return jump functions, relying on the acyclic call graph later passes reveal that the variable is aliased. Even
to limit the number of invocations. though the jump functions are constructed as a part of a
Clearly the return jump functions can also be very monolithic process that examines the whole program at
useful in optimizing code for a single module. They pro- once, it is useful to arrange the evaluation of the jump
vide a clean representation of the effect of executing a function to interrogate the interprocedural MOD and alias
procedure in the presence of values specific to the call information because it avoids an extra pass over the
site. Because of this, they can be used to provide some source of the individual modules. If this were not done,
of the benefits of inline expansion. We plan to evaluate PFC would need to reread the source after computing
their usefulness in the optimizing module compiler for MOD and alias information to construct the jump func-
the IR” environment. tions. Hence, the method designed for use in a program-
ming environment is also suitable for a more traditional
compiling framework.
5. Implementation
In addition to jump functions that map from con-
We have implemented essentially the full symbolic stants available upon procedure entry to values avail-
constant propagation system using both side effect and able at call sites, return jump functions are also con-
returned constant information in the Rice vectorizing structed. In addition to the advantages already stated,
compiler system, called PFC [AlKe 841. In this section this permits a natural treatment of BLOCK DATA subrou-
we describe some of the details of that implementation. tines in Fortran. If special dummy calls to the BLOCK
PFC is a monolithic system which accepts all the DATA routines are inserted at the beginning of each pro-
modules of a program and analyzes them in two passes. cedure that uses the COMMON blocks they initialize,
The first pass builds the call graph and records the local return jump functions provide a rich source of constants
information needed to support side effect analysis, alias to be propagated throughout the program. Since BLOCK
analysis and constant propagation. The next pass com- DATA subroutines are the only way to initialize common
putes interprocedural information by solving data flow blocks in Fortran, this is a particularly useful technique
problems on the program’s call graph. Finally, each pro- for that language.
cedure is individually vectorized using the computed Once MOD information is available, all of the
interprocedural information, expression trees are traversed and if the first type of
In propagating constants, the jump functions are dummy node is encountered, then the call site and
represented by expression trees, in which interior nodes parameter position are checked to see if the actual
are labelled with arithmetic operators and leaves are parameter could be modified by the call site. If so, that
labelled with constants and variables. The variables are subtree is replaced by the output expression of the rou-
either scalar forma1 parameters or scalar COMMON vari- tine with the variables in the output expression replaced
ables. These expressions are initially built after parsing with appropriate input values at the call site. A side
but before interprocedural side effect analysis informa- benefit of this approach is that if a subroutine initializes
tion or aliasing information is available. some constants, those constant values will be detected
and propagated to other routines.
159

9. In this implementation, strongly-connected regions The approach is linear in the size of the call graph if we
in the call graph are identified to support the algorithm assume that the number of input parameters to each
for computing interprocedural side effects. For most procedure is bounded, that the jump functions all have
Fortran 77 programs, the call graph will be acyclic, per- bounded support, and that the evaluation time for each
mitting the procedures to be processed in reverse topo- jump function is bounded by a constant.
logical order, sometimes called reuerse invocation order An experimental implementation in the Rice vec-
[Alle 741, to derive a solution to the side effect problem torization system PFC has established the practicality of
in linear time. The use of reverse invocation order also the approach. We are currently implementing the algo-
benefits constant propagation because jump functions rithm in the program compiler of the lRn programming
need not be checked any further when a dummy node is environment. We believe that the technique presented
replaced with the output expression corresponding to a here will approach the method of inline substitution for
procedure invocation. Parameters modified inside a effectiveness. We expect to evaluate this algorithm in
recursive region are assumed to be variant. Any vari- two ways: directly in our own compiler and by using lRn
able involved in an alias with a variable which is as a preprocessor to generate modified source for compi-
modified is assumed to be nonconstant. lation by existing optimizing compilers like IBM’s VS
Once the effects of aliasing and the side effects of Fortran and DEC’s VMS Fortran.
external procedure calls have been incorporated into the There is one important extension to the technique
expression trees representing the jump functions, the presented here. The constant propagation lattice can be
actual propagation is straightforward. The strongly con- replaced by any lattice of bounded depth, yielding an
nected regions are visited in topological order and each algorithm that might be used for other purposes such as
procedure in each region is processed. If every incoming propagating inequalities. Such information could be
edge assigns a variable the same constant value, then used to improve the performance of vectorization sys-
that variable is deemed constant with that value at pro- tems like PFC, in which the knowledge that a parameter
cedure invocation. Otherwise the variable is assigned is greater than “0” or greater than “1” might make an
the special value 1. Finally, each edge in the procedure otherwise unsafe transformation possible [AlKe 841.
is visited and the expression trees evaluated to yield
values for the associated parameters.
7. References
This implementation differs from the general algo-
rithm of Section 3 in that it will not identify constants
[AhUl 771 A. Aho and J. Ullman. Principles of Com-
that are passed into a recursive region then passed
piler Design. Addison-Wesley. 1977.
around a set of recursive calls. This is because the imple-
mentation was undertaken before we discovered the [Alle 74) F. E. Allen. Interprocedural data flow
“optimistic” algorithm of Figure 4. A straightforward analysis. Proceedings IFIP Congress 74,
revision of the implementation to use the optimistic North-Holland Publishing Co.: Amsterdam.
algorithm is underway. In any case, this deficiency is 1974.
less important for Fortran, because the current standard (AIKe 841 J. R. Allen and K. Kennedy. PFC: a pro-
precludes dynamic recursion. gram to convert Fortran to parallel form.
We have not yet tried the system on a large Supercomputers: Design and Application8 (K.
variety of programs, so it would be premature to report Hwang, ed.). IEEE Computer Society Press,
any empirical evidence about the value of interpro- 1984.
cedural constant propagation. We plan to report these [Ball 791 J. E. Ball. Predicting the effects of optimi-
results as a part of a general study of interprocedural zation on a procedure body. Proceedings of
data flow analysis in PFC. SIGPLAN ‘79 Symposium on Compiler Con-
struction, SIGPLAN Notices, 14(8). 1979.
6. Conclusions [Coop 83) K. D. Cooper. Interprocedural information
in a programming environment. Ph.D.
We have presented an efficient procedure for com-
Dissertation, Department of Mathematical
puting interprocedural constants in a programming
Sciences, Rice University, Houston, TX.
environment. The method is based on an algorithm
May 1983.
adapted from the single-procedure methods of Reif and
Lewis [ReLe 821 and Wegman and Zadeck [WeZa 851.
160

10. [Coop 851 K. D. Cooper. Analyzing aliases of reference [ReLe 821 J. H. Reif and H. R. Lewis. Symbolic
forma1 parameters. Proceedings of Twelfth evaluation and the global value graph. TR
POPL. 1985. 37-82, Aiken Computation Laboratory, Har-
[CoKe 841 K. D. Cooper and K. Kennedy. Efficient vard University. 1982.
computation of flow insensitive interpro- [Sche 771 R. W. Scheifler. An analysis of inline substi-
cedural summary information. Proceedings tution for a structured programming
of SIGPLAN ‘84 Symposium on Compiler language. Communications of the ACM,
Construction, SIGPLAN Notices, 19(6). 1984. 20(9). 1977.
(CoKT 851 K. D. Cooper, K. Kennedy, and L. Torczon. (Tort 851 L. Torczon. Compilation dependences in an
The impact of interprocedural analysis and ambitious optimizing compiler. Ph.D.
optimization on the design of a software Dissertation, Department of Computer Sci-
development environment. Proceedings of ence, Rice University, Houston, TX. May
SIGPLAN ‘85 Symposium on Language 1985.
Issues in Programming Environment, SIG- [WeZa 85) M. Wegman and F. K. Zadeck. Constant
PLAN Notices, 20(7). July 1985. propagation with conditional branches.
[COKT 861 K. D. Cooper, K. Kennedy and L. Torczon. Proceedings of Twelfth POPL. 1985.
Optimization of compiled code in the lRn
programming environment. Proceedings of
the Nineteenth Annual Hawaii International
Conference on Systems Sciences. January,
1986.
]Dong 801 J. Dongarra. LINPACK working note #3:
FORTRAN BL4S timing. Technical Report
ANL-80-24, Argonne National Laboratory,
February 1980.
[DBMS 791 J. J. Dongarra, J. R. Bunch, C. B. Moler,
and G. W. Stewart. LINPACK Users’
Guide. SIAM, Philadelphia. 1979.
[HoKe 851 R. T. Hood and K. Kennedy. A program-
ming environment for Fortran. Proceedings
of the Eighteenth Annual Hawaii Interna-
tional Conference on Systems Sciences, 1985.
[KaUI 771 J. Kam and J. Ullman. Monotone data flow
analysis frameworks. Acta Injormatica, 7.
1977.
[Kenn 781 K. Kennedy. Use-definition chains with
applications. J. Computer Languages, 3(3).
1978.
[Kenn 811 K. Kennedy. A survey of data flow analysis
techniques. Program Flow Analysis: Theory
and Applications (S.S. Muchnick and N.D.
Jones, eds.). Prentice-Hall. 1981. pp. 5-54.
[Kild 73) G. Kildall. A unified approach to global
program optimization. Proceedings of First
POPL. 1973.
[Myer 811 E. W. Myers. A precise inter-procedural
data flow algorithm. Proceedings of Eighth
POPL. 1981.
161