INTERPROCEDURAL ANALYSIS

Transcription

1 INTERPROCEDURAL ANALYSIS Interprocedural Analysis gathering information about the entire program rather than single Alias Analysis Call Graph Construction Interprocedural Level Optimizations make changes that involve s Constant Propagation Inlining 1

2 MOTIVATION Why consider analysis & optimization of whole programs? 1. To produce better code around call sites Avoid saves & restores Understand cross-call data flow 2. To produce tailored copies of s Often, full generality is unneeded Constant-valued parameters & globals, aliases 3. To provide sharper global analysis Improve on conservative assumptions Particularly true for global variables 4. To present the optimizer with more context Languages (& programs) with short s Assumes that context improves code quality FACT VERSUS FOLKLORE Folklore : Create a single large graph & optimize it all Get all the benefits of analyzing the whole program See all the opportunities This should show the upper bound on improvement Fact: The details get in the way Single methods get overwhelmed with details Imagine a data-flow analysis with all the names Two choices summarization or slow compilation And most of the detail is local Not clear that this approach leads to better code It does lead (inexorably ) to slower compilation 2

3 FACT VERSUS FOLKLORE Folklore : Overhead of calls is significant For small s, linkage can dominate useful work Should eliminate calls whenever possible (avoid the cost ) Lead scientific programmers to nonmodular style Fact : Calls have costs, but they also have benefits Actual costs are a function of size and call frequency Calls provide a much needed separation of concerns Imagine nesting all those register lifetimes Eliminating calls can slow the code down FACT VERSUS FOLKLORE : Modular codes need interprocedural optimization : Folklore Higher ratio of calls to real work Less straight-line code for optimizer Fact Opportunities are limited Smaller s have smaller name spaces Fewer interactions to improve Fewer common overheads, like address expressions Procedure call optimization is more important Calls take a larger fraction of the time Inline calls to eliminate linkages & create context Avoid copying & dereferencing parameters 3

4 WHAT MAKES THIS DIFFICULT? Different calls to p have different properties Frequency of the call Environment that p inherits Mapping from parameters to value (& locations) Constant values & known values Size of task Surrounding execution context Is call in a parallel loop? Which registers are unused? Procedure-valued parameters (OOP) m 1, p n May want to optimize distinct calls differently WHAT MAKES THIS DIFFICULT? joe(i,j,k) l 2 * k if (j = 100) then m 10 * j else m i call ralph(l,m,k) o m * 2 q 2 call ralph(o,q,k) write q, m, o, l What happens at a call? main call joe( 10, 100, 1000) ralph(a,b,c) b a * c / 2000 Use worst case assumptions about side effects Leads to imprecise intraprocedural information Leads to explosion in intraprocedural def-use chains Since j = 100 this always executes the then clause and always m has the value 1000 What value is printed for q? Did ralph() change it? 4

5 EXAMPLE INTERPROCEDURAL PROBLEMS Modification and Side Effects The modification side effect set of a call at s, MOD(s), is the set of all variables that may be modified as a side effect of the call at s. The reference side effect set REF(s) is the set of variables that may be referenced as a side effect of the call at s. Alias Analysis For a p and a formal parameter x passed to p, the alias set ALIAS(s,x) is the set of variables that may refer to the same location as x on entry to s. EXAMPLE INTERPROCEDURAL PROBLEMS Kill Analysis For a given call site s, the kill side effect set KILL(p) is the set of variables that are assigned on every path through p invoked at s and s invoked from within p. Constant Propagation Given a program and a p within that program, the set of interprocedural constants CONST(p) contains the variables that have known constant values on every invocation of p. For a variable v in CONST(p), valin(x,p) is a function returning the value of x on entry to p 5

6 EXAMPLE INTERPROCEDURAL PROBLEMS Live Analysis For a given call site s, which invokes p, the use side effect set USE(s) is the set of variables that have an upwards-exposed use in p A variable is live at a call site s if x in USE(s) or if there is a path through the called at s that does not assign a new value to x and x is live at some control flow successor of s WHAT MAKES THIS DIFFICULT? joe(i,j,k) l 2 * k if (j = 100) then m 10 * j else m i With perfect call ralph(l,m,k) knowledge, the compiler o could m * 2 replace this with write q 1000, , 2000, 2000 call ralph(o,q,k) and the rest is dead! write q, m, o, l What happens at a call? main call joe( 10, 100, 1000) ralph(a,b,c) b a * c / 2000 Use worst case assumptions about side effects Leads to imprecise intraprocedural information Leads to explosion in intraprocedural def-use chains Since j = 100 this always executes the then clause and always m has the value 1000 What value is printed for q? Did ralph() change it? 6

7 INTERPROCEDURAL ANALYSIS: CLASSIFICATION Definitions May problems describe events that might happen in a call MOD() sets include any name the call might define REF() sets include any name the call might use USE() sets Must problems describe events that always happen in a call KILL() INTERPROCEDURAL ANALYSIS: CLASSIFICATION Definitions Computation can consider or ignore control-flow in Flow-insensitive analysis ignores intraprocedural control-flow Flow-sensitive analysis tracks intraprocedural control-flow 7

8 INTERPROCEDURAL ANALYSIS: CLASSIFICATION A R1 R2 A B B MOD(R1) = MOD(A) + MOD(B) KILL(R1) = KILL(A) + KILL(B) USE(R1) = USE(A) + ( KILL(A) USE(B)) MOD(R2) = MOD(A) + MOD(B) KILL(R2) = KILL(A) KILL(B) USE(R2) = USE(A) + USE(B) An interprocedural dataflow problem is flow insensitive iff the value of the solution on both sequentially and alternatively composed regions is determined by taking the union of the solutions for the sub regions. INTERPROCEDURAL ANALYSIS: CLASSIFICATION Definitions Side effect problems ask about what might (or must) happen as a side effect of a call MOD() sets include any name the call might define REF() sets include any name the call might use USE() sets Propagation problems ask about what conditions may or must hold upon entry ALIAS() CONST() 8

9 INTERPROCEDURAL ANALYSIS Classical Problems have appeared in the literature Constructing the call graph May summary problems MOD & REF Alias tracking ALIAS Constant propagation CONST Kill information KILL New-fangled problems appear all the time Alignment propagation for caches Propagating data distributions for FORTRAN D Placing instrumentation & picking checkpoints INTERPROCEDURAL ANALYSIS The modification side effect set of a call at s, MOD(s), is the set of all variables that may be modified as a side effect of the call at s. MOD(s) = DMOD(s) x DMOD(s) Alias(p,x) DMOD(s) - the set of variables visible at s that may be modified by executing p without taking aliasing into account. Alias(p,x) = set of variables that may be aliased to x on entry to p Flow-insensitive approach Assume FORTRAN semantics no pointers, no nesting (local/global only), parameters passed by reference 9

10 INTERPROCEDURAL ANALYSIS DMOD(s) = {v p invoked at s, v s w and w GMOD(p)} v s w actual parameter v is bound to formal parameter w at call site s GMOD(p) set of global variables and formal parameters of p that are modified, either directly or indirectly, as a result of the invocation of p CALL P(A,B,C) SUBROUTINE P(X,Y,Z) INTEGER X,Y,Z X = X * Z Y = Y * Z END DMOD = {A,B} GMOD(P) = {X,Y} INTERPROCEDURAL ANALYSIS GMOD(p) = IMOD(p) s=(p,q) {z z s w and w GMOD(q)} IMOD(p) immediate modification side effect set variables explicitly modified in p 10

11 EXAMPLE S 0 S 1 SUBROUTINE P INTEGER A CALL S(A,A) END SUBROUTINE S(X,Y) INTEGER X,Y CALL Q(X) END SUBROUTINE Q(Z) INTEGER Z Z = 0 END GMOD(P) = IMOD(P) A, since A S 0 X and X GMOD(Q) GMOD(S) = IMOD(S) X, since X S 1 Z and Z GMOD(Q) P {} S {} IMOD(p) Q {Z} EXAMPLE S 0 S 1 SUBROUTINE P INTEGER A CALL S(A,A) END SUBROUTINE S(X,Y) INTEGER X,Y CALL Q(X) END SUBROUTINE Q(Z) INTEGER Z Z = 0 END A X Y Binding Graph captures the parameter relationships 1. Construct a vertex for each formal parameter f of every 2. Construct a directed edge from formal parameter f1 to formal parameter f2 if a call ties the two Z 11

12 SYSTEM DEPENDENCE GRAPHS Data structure representing the relationships between a system of s rather than a monolithic program Built on program dependence graphs (PDG) PDGs connected by additional dependence edge types EXAMPLE PDG main() sum := 0 i := 1 while i < 11 do sum := sum + i i := i + 1 od end(sum,i) T ENTRY T T T T sum := 0 i := 1 while i < 11 final(i) final(sum) T T sum := sum + i i := i + 1 Control Loop carried flow Loop independent flow Output 12

13 SYSTEM DEPENDENCE GRAPHS Should be possible to build dependence graphs with minimal knowledge of other systems components Should be possible to link these together with additional nodes and edges to represent the call sites. Should be useful for precise slicing SYSTEM DEPENDENCE GRAPH Assumptions: main with auxiliary s s end with return statement parameters are value/result no calls of form P(x,x) or P(g) where g is a global (no aliasing). 13

14 EXAMPLE program Main sum := 0; i := 1; while i < 11 do call A(sum,i); return Add(a,b) a := a + b; return A(x,y) call Add(x,y); call Inc(y); return Inc(z) call Add(z,1); return CALL GRAPH Main A Add Inc 14

15 ENTRY main sum := 0 i := 1 while i < 11 final(sum) final(i) program Main sum := 0; i := 1; while i < 11 do call A(sum,i); return ENTRY A call Add call Inc call A A(x,y) call Add(x,y); call Increment(y); return ENTRY Inc ENTRY Add a := a + b Add(a,b) a := a + b; return Call Add Inc(z) call Add(z,1); return PROCEDURE CALLS AND PARAMETER PASSING Call by value/result parameter passing represented using 4 different types of parameter vertices: actual-in, actual-out formal-in and formal-out Actuals control dependent on call. Formals control dependent on entry node Use of temporary variables for passing in and out information. 15

16 ENTRY main sum := 0 i := 1 while i < 11 final(sum) final(i) program Main sum := 0; i := 1; while i < 11 do call A(sum,i); return call A x_in := sum y_in := i sum:= x_out i := y_out Inc(z) call Add(z,1); return z:=z_in ENTRY Inc Call Add z_out:=z a_in := z b_in := 1 z:=a_out x:=x_in y:=y_in call Add ENTRY A call Inc a_in := x b_in := y x:=a_out y:=b_out z_in := y y:= z_out x_out:=x y_out:=y A(x,y) call Add(x,y); call Increment(y); return ENTRY Add a:=a_in b:=b_in a := a + b a.out:=a b_out:=b Add(a,b) a := a + b; return 16

17 PROCEDURE CALLS AND PARAMETER PASSING Caller - The value of the actual parameters get ``copied'' to the temporary sites (actual-in) one per parameter. The return value is copied from a different temporary site (actual-out). Callee - similar operation from formal-in and formal-out. Dependencies between actual-in and formal-in as well as formal-out and actual-out. CALL GRAPH CONSTRUCTION Graphical representation of the calling structure of a program. Important in this kind of analysis. Nodes: s and functions of a program Edges: represent potential calls between the nodes Cycles in the graph represent recursion May be a multi-graph multiple calls between two s result in multiple edges between them. 17

18 BUILDING CALL GRAPHS main() call g() call h() call g() end f g() call h() call i() end g j() end j i() call g() call j() end i h() end h h main i g j CONSTRUCTING THE CALL GRAPH PROCEDURE/FUNCTION PARAMETERS main call confuse(a,c) call confuse(b,d) confuse(x,y) call x(y) main confuse a(z) call z() b(z) call z() a b c() d()... c Imprecise Precise call graph d 18

19 CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) call v(u,u) end b call w(b,c) end c d(y,z) call y(c,c) end d a c b d CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) end b checked: b(d,c) call w(b,c) end c call y(c,c) end d a c b d 19

20 CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) c(d,d) end b checked: b(d,c),c(d,d) call w(b,c) end c call y(c,c) end d a c b d CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) end b checked: b(d,c),c(d,d),d(b,c) call w(b,c) end c call y(c,c) end d d(b,c) a c b d 20

21 CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) call w(b,c) b c end a end c b(u,v) d(y,z) call v(u,u) end b call y(c,c) end d checked: b(d,c),c(d,d),d(b,c),b(c,c) b(c,c) a c b d CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) end b c c c(c,c) call w(b,c) end c call y(c,c) end d checked: b(d,c),c(d,d),d(b,c),b(c,c),c(c,c) a c b d 21

22 CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a call w(b,c) end c b(u,v) d(y,z) call v(u,u) call y(c,c) end b end d c c c(b,c) checked: b(d,c),c(d,d),d(b,c),b(c,c),c(c,c),c(b,c) a c b d CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a call w(b,c) end c b(u,v) d(y,z) call v(u,u) call y(c,c) end b end d b c b(b,c) checked: b(d,c),c(d,d),d(b,c),b(c,c),c(c,c),c(b,c),b(b,c) a c b d 22

23 CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) end b c(b,b) b c call w(b,c) end c call y(c,c) end d checked: b(d,c),c(d,d),d(b,c),b(c,c),c(c,c),c(b,c),b(b,c),c(b,b) a c b d CALL GRAPHS PROCEDURE/FUNCTION PARAMETERS a c(w,x) call b(d,c) end a b(u,v) d(y,z) call v(u,u) end b call w(b,c) end c b b call y(c,c) end d b(b,c) repeat a c b d checked: b(d,c),c(d,d),d(b,c),b(c,c),c(c,c),c(b,c),b(b,c),c(b,b) 23

24 ALIAS ANALYSIS Determination of storage locations that may be accessed in more than one way Pointers Formal/Global Formal/Formal p = &a int p int x q = p p, int q) one(int q) two(int * * body of one * body of two one(p) two(x,x) In all 3 examples, p and q are aliases at the point marked with * ALIASES Influences all of the analysis we have talked about Finding full range of aliases essential to correctness Smallest possible set of aliases essential to aggressive optimization 24

25 INTERPROCEDURAL ANALYSIS VS. INTERPROCEDURAL OPTIMIZATION Interprocedural analysis Gather information across multiple s (typically across the entire program) Can use this information to improve intraprocedural analyses and optimization Interprocedural optimizations Optimizations that involve multiple s e.g., Inlining, cloning, interprocedural register allocation Optimizations that use interprocedural analysis DIMENSIONS OF INTERPROCEDURAL ANALYSIS Flow-sensitive vs. flow-insensitive Context-sensitive vs. context-insensitive Path-sensitive vs. path-insensitive 25

26 FLOW (IN)SENSITIVE ANALYSIS Flow-sensitive analysis Computes one answer for every program point Requires iterative data-flow analysis or similar technique Flow-insensitive analysis Ignores control flow Computes one answer for every Can compute in linear time Less accurate than flow-sensitive FLOW SENSITIVITY EXAMPLE Flow-sensitive analysis Computes an answer at every program point: x is 4 after the first assignment x is 5 after the second assignment Flow-insensitive analysis Computes one answer for the entire : x is not constant int f(int x) { return x*x} 26

27 CONTEXT SENSITIVITY Context-sensitive analysis Re-analyzes callee for each caller Also known as polyvariant analysis Context-insensitive analysis Perform one analysis independent of callers Also known as monovariant analysis Context-sensitive analysis Computes an answer for every callsite: x is 4 in the first call x is 5 in the second call Context-insensitive analysis Computes one answer for all callsites: x is not constant Suffers from unrealizable paths: Can mistakenly conclude that id(4) can return 5 because wemerge information from all callsites 27

28 PATH SENSITIVITY Path-sensitive analysis Computes one answer for every execution path Subsumes flow-sensitivity Extremely expensive Used in software verification via model checking Path-insensitive Assumes current program point can be reached by all possible incoming points PATH SENSITIVITY EXAMPLE Is x constant? Path-sensitive analysis Computes an answer for every path: x is 4 at the end of the left path x is 5 at the end of the right path Path-insensitive analysis Computes one answer for all path: x is not constant 28

29 { } int x, y, a; int *p; p = &a; x = 5; foo(&x); y = x + 1; foo (int *p) { return p; } Is x constant? With a supergraph, run our same IDFA algorithm Determine that x = 5 29

30 BRUTE FORCE: FULL CONTEXT-SENSITIVE INTERPROCEDURAL ANALYSIS Invocation Graph [Emami94] Use an invocation graph, which distinguishes all calling chains Re-analyze callee for all distinct calling paths Pro: precise Cons: exponentially expensive, recursion is tricky void foo(int b) { hoo(b); } void goo(int c) { hoo(c); } main() { int x, y; foo(x); goo(y); } 30

31 void f() { g() g() h() } Void g() { h() i() } Void h() { } Void i(){ g() j() } Void j() { } INTERPROCEDURAL ANALYSIS: SUMMARIES Compute summary information for each Summarize effect of called for callers Summarize effect of callers for called Store summaries in database Use later when optimizing s Pros Concise Can be fast to compute and use Separate compilation practical Cons Imprecise if only have one summary per 31

32 TWO TYPE OF INFORMATION Track information that flows into a Sometimes known as propagation problems e.g., What formals are constant? e.g., Which formals are aliased to globals? Track information that flows out of a Sometimes known as side effect problems e.g., Which globals are def d/used by a? e.g., Which locals are def d/used by a? e.g., Which actual parameters are def d by a? EXAMPLES Propagation Summaries MAY-ALIAS: The set of formals that may be aliased to globals and each other MUST-ALIAS: The set of formals that are definitely aliased to globals and each other CONSTANT: The set of formals that must be constant Side-effect Summaries MOD: The set of variables possibly modified (defined) by a call to a REF: The set of variables possibly read (used) by a call to a DEF: The set of variables that are definitely defined by a (e.g., killed in the liveness sense) 32

33 COMPUTING INTERPROCEDURAL SUMMARIES Top-down Summarize information about the caller (MAY-ALIAS, MUST-ALIAS) Use this information inside the body int a; void foo(int &b, &c){... } foo(a,a); Bottom-up Summarize the effects of a call (MOD, REF, DEF) Use this information around calls x = 7; foo(x); y = x + 3; CONTEXT-SENSITIVITY OF SUMMARIES None ( zero levels of the call path ) Top-down: Meet (or smear) information from all callers to particular callee Bottom-up: Use side-effect information for callee at all callsites Callsite ( one level of the call path ) Top-down: Label data-flow information with callsite Bottom-up: Affects alias analysis, which in turn affects side-effects 33

34 CONTEXT-SENSITIVITY OF SUMMARIES k levels of call path (k-limiting) Forward propagation: Label data-flow information with k levels of the call path Side-effects: label side-effects with k levels of call path INTERPROCEDURAL CONSTANT PROPAGATION (ICP) Information flows from caller to callee and back int a,b,c,d; void foo(e){ a = b + c; d = e + 2; } foo(3); Interprocedural Alias Analysis The calling context tells us that the formal e is bound to the constant 3, which enables constant propagation within foo() After calling foo() we know that the constant 5 (3+2) propagates to the global d Top-down: aliasing due to reference parameters Bottom-up: points-to relationships due to multilevel pointers 34

35 INTERPROCEDURAL CONSTANT PROPAGATION [CALLAHAN, ET AL 86] Basic Idea Extend the global constant propagation by using an extension of the CFG, the interprocedural value graph, which represents the movement of values across calls Can be either context-sensitive or context-insensitive Jump Functions For a call of q at site s, Js x determines the value of the formal parameter x based on the inputs to the p that calls q The support of Js x is the set of inputs to p actually used to compute Js x Interprocedural Value Graph Create one node for each jump function Js x If x support(jt y ) for some call site t in the, then construct an edge from Js x to Jt y (Connect Js x with nodes that use the value of x) JUMP FUNCTION 35

36 MORE ABOUT JUMP FUNCTION How do we handle return values? Create return jump functions that pass values from callees to callers R s x determines the value of x upon return from p Add nodes and edges for R s x to the interprocedural value graph Types of jump functions Jump functions determine the value of a parameter How should they determine these values? Symbolic interpretation Conditional constants Simple constants Simple constants seem to do well 36

37 ALTERNATIVE TO INTERPROCEDURAL ANALYSIS: INLINING Idea Replace call with body Pros Reduces call overhead Exposes calling context to body Exposes side effects of to caller Simple Cons Code bloat (decrease efficacy of caches, branch predictor, etc) Can t always statically determine callee (e.g., in OO languages) Library source is usually unavailable Can t always inline (recursion) INLINING POLICIES The hard question How do we decide which calls to inline? Many possible heuristics Only inline small functions Let the programmer decide using an inline directive Use a code expansion budget [Ayers, et al 97] Use profiling or instrumentation to identify hot paths inline along the hot paths [Chang, et al 92] JIT compilers do this Use inlining trials for object oriented languages [Dean & Chambers 94] Keep a database of functions, their parameter types, and the benefit of inlining Keeps track of indirect benefit of inlining Effective in an incrementally compiled language 37

38 ALTERNATIVE TO INTERPROCEDURAL ANALYSIS: CLONING Procedure Cloning/Specialization Create a customized version of for particular call sites Compromise between inlining and interprocedural optimization Pros Less code bloat than inlining Recursion is not an issue (as compared to inlining) Better caller/callee optimization potential (versus interprocedural analysis) Cons Still some code bloat (versus interprocedural analysis) May have to do interprocedural analysis anyway e.g. Interprocedural constant propagation can guide cloning EVALUATION Many compilers avoid interprocedural analysis It s expensive and complex Not beneficial for most classical optimizations Separate compilation + interprocedural analysis requires recompilation analysis [Burke and Torczon 93] Can t analyze library code When is it useful? Pointer analysis Constant propagation Object oriented class analysis Security and error checking Program understanding and re-factoring Code compaction Parallelization 38

39 OTHER TRENDS Cost of s is growing More of them and they re smaller (OO languages) Modern machines demand precise information (memory op aliasing) Cost of inlining is growing Code bloat degrades efficacy of many modern structures Procedures are being used more extensively Programs are becoming larger Cost of interprocedural analysis is shrinking Faster machines Better methods 39