Interprocedural Optimizations

CS 671April 8, 2008

2 CS 671 – Spring 2008

Modularity is a Virtue

• Decomposing programs into procedures aids in readability and maintainability• Object-oriented languages have pushed this

trend even further• In a good design, procedures should be:

– An interface– A black box

3 CS 671 – Spring 2008

The Catch

• This inhibits optimization! • The compiler must assume:

– Called procedure may use or change any accessible variable

– Procedure’s caller provides arbitrary values as parameters

• Interprocedural optimizations – use the calling relationships between procedures to optimize one or both of them• Examples:

– f(i,j,k) where i=2 … constant propagation in f!– f(i,j,k) where i={2,5} … new f_2() and f_5() clones

4 CS 671 – Spring 2008

Interprocedural Optimizations

• Until now, we’ve only considered optimizations “within a procedure”• Extending these approaches outside of the

procedural space involves similar techniques:– Performing interprocedural analysis•Control flow •Data flow

– Using that information to perform interprocedural optimizations

5 CS 671 – Spring 2008

Terminology

int a, e // globalsprocedure foo(var b, c) // formal args

b := cendprogram main

int d // localsfoo(a, d) // call site with

end // actual args

In procedure body• formals and/or globals may be aliased (two names refer

to same location)• formals may have constant value

At procedure call• global vars may be modified or used• actual args may be modified or used

6 CS 671 – Spring 2008

Call Graphs

1 procedure f() {2 call g()3 call g()4 call h()5 }6 procedure g() {7 call h()8 call i()9 }10 procedure h { }11 procedure i() {12 call g()13 call j()14 }15 procedure j { }

Invocation order – process procedure before its callees

Reverse invocation order – process procedure after its callees

f

g h

i j

2,3

7 12

13

4

8

7 CS 671 – Spring 2008

Partial Call Graphs

1 procedure f() {2 call g()3 call g()4 call h()5 }6 procedure g() {7 call h()8 call i()9 }10 procedure h { }11 procedure i() {12 call g()13 call j()14 }15 procedure j { }

What if we compile at different times?

f

g h

i

2,3

7

4

8g

i j

12

13

8 CS 671 – Spring 2008

Dealing with Procedures

Aliasing example

int afoo(a, a)...procedure foo(var b, c)a := 1 // what is b, c?b := 2 // what is a, c?c := 3 // what is a, b?d := a + b // what is d?

end

Side effect example

a := 1foo(a) // used/killed?b := a // what is b?

Constants example

foo(1)...procedure foo(a) if (a = 1) // what is a?...

9 CS 671 – Spring 2008

Interprocedural Compilation

Goals• enable standard optimizations even in presence of

procedure calls• perform additional optimizations not possible for

single procedures• reduce call overhead for procedures

Issues• compilation speed• re-engineering compiler• separate compilation• recompilation analysis• libraries (no source code)• dynamic shared objects (DSOs)

10 CS 671 – Spring 2008

Interprocedural Analyses (IPA)

• MAY-ALIAS may be aliased• MUST-ALIAS must be aliased• MOD may be modified• REF may be referenced• USE may be used before kill• KILL must be killed• AVAIL must be available• CONSTANT must be constant

11 CS 671 – Spring 2008

Parameter Binding

At procedure boundaries, we need to translate formal arguments of procedure to actual arguments of procedure at call site

int a,bprogram main // MOD(foo) = bfoo(b) // REF(foo) = a,b

endprocedure foo (var c) // GMOD(foo)= bint d // GREF(foo)= a,bd := bbar(b) // MOD(bar) = b

end // REF(bar) = aprocedure bar (var d)if (...) // GMOD(bar)= d

d := a // GREF(bar)= aend

GMOD, GREF = side effect of procedureMOD, REF = effect at call site (perhaps specific to call)

12 CS 671 – Spring 2008

Direction of IPA

Bottom-up – summarizes call effect (MOD, REF, USE, KILL)procedure foo

int abar(a)

endTop-down – summarizes info from caller (MAY-ALIAS)int a,bprocedure foo(var int b, c) ...endfoo(a,a)foo(a,b)

Bi-directional – info to/from caller/callee (AVAIL, CONST)int a,b,c,dprocedure foo(e)

a := b + cd := e

endfoo(1)

13 CS 671 – Spring 2008

Interprocedural Analyses

Flow-insensitive• interprocedural analysis summarizes all paths• what “may” happen (happens on at least one path)

Flow-sensitive • interprocedural analysis indicates what must happen

on all paths

14 CS 671 – Spring 2008

Precision of IPA

Flow-insensitive (MAY-ALIAS, MOD, REF)• result not affected by control flow in procedure

Flow-sensitive (USE, KILL, AVAIL)• result affected by control flow in procedure

A

BA B

15 CS 671 – Spring 2008

Flow-Insensitive Aliases w/out Pointers

For some languages, aliases arise only due to parameter passing

We can compute solutions efficiently by separating local/global portions of solution

1. calculate where aliases are introduced (needs only local information)

2. propagate aliases

Reduce complexity further by finding global-formal and formal-formal aliases separately

Flow-insensitive alias algorithm1. find global-formal aliases2. find formal-formal aliases3. combine

16 CS 671 – Spring 2008

Alias Analysis

• Variables x, y are aliased in procedure p if they may refer to the same memory location in p• alias pair <x,y> MAY-ALIAS

• Aliases are introduced when the same variable is passed to two different locations in the same call• the formals become an alias pair

procedure bar(int c)foo(c,c)

endprocedure foo(var a, b)

... // <a,b> in ALIASend

• There is a visible (global) variable in both the caller and callee passed as an actual parameter• global and formal become an alias pair

int bfoo(b)procedure foo(var a)

... // <a,b> in ALIASend

17 CS 671 – Spring 2008

Alias Analysis (cont)

Aliases are propagated when p calls q and two formals in p which are aliases are used as actuals in the same call q,• the formals in q become aliases

p(a,a)procedure p(var b, c)

q(b,c)endprocedure q(var d, e)

... // <d,e> in ALIASend

When a variable aliased to a global is passed as a parameter to q,• formal in q becomes aliased to global

int ap(a)procedure p(var b)

q(b)endprocedure q(var c)

... // <a,c> in ALIASend

18 CS 671 – Spring 2008

Alias Analysis (cont)

Aliases are propagated when p calls q and when two actuals are aliased to the same global• the formals become aliases

int ap(a)procedure p(var b)q(a,b)

endprocedure q(var c, d)... // <c,d> in ALIAS

end

19 CS 671 – Spring 2008

Interprocedural Optimizations

• Tail call & tail recursion elimination• Inlining• Leaf-routine optimization & shrink wrapping• Interprocedural constant propagation• Interprocedural register allocation• Aggregation of global references

20 CS 671 – Spring 2008

Tail Call & Tail Recursion Elimination

• Transformation that applies to calls• Reduce procedure-call overhead and enable

additional optimizations• A call from procedure f() to procedure g() is a tail

call if the only thing f() does, after g() returns to it, is itself return• The call is tail recursive if f() and g() are the same

21 CS 671 – Spring 2008

Inlining

• Replaces calls to procedures with copies of their bodies• Converts calls from opaque objects to local

code– Exposes the “effects” of the called procedure– Extends the compilation region• Language support: the inline attribute

– But the compiler can decide per call-site, rather than per procedure

22 CS 671 – Spring 2008

Inlining Decisions

Must be based on • Heuristics, or• Profile information

Considerations• The size of the procedure body (smaller=better)• Number of call sites (1=usually wins)• If call site is in a loop (yes=more optimizations)• Constant-valued parameters

23 CS 671 – Spring 2008

An Interesting Experiment

• Cooper, Hall, Torczon (92)

• Integrated 44% of call sites

• Reduced dynamic calls by 98%

• 8% performance degradation on MIPS R2000!

• Suspect: Cache effects or register pressure in a critical loop

• Culprit: Fortran 77 conventions (assumes no aliasing on procedure entry)

24 CS 671 – Spring 2008

Leaf-Routine Optimization

Leaf routine• A procedure that is a leaf in the call graph• It calls no other procedures

Leaf routine optimization• Simplifies the way parameters are passed to a leaf

routine• Removes much of the procedure prologue and

epilogue• Depends on the calling convention and temporary

storage requirements

How many procedures are leaf routines? (Hint: think of a binary tree)

25 CS 671 – Spring 2008

Leaf-Routine Optimization

Determine amount of storage (registers and stack space) required• If register usage is less than caller-save and scratch

registers – use them exclusively• If no stack space required, delete stack preparation

code

If procedure is small, instead consider inlining

26 CS 671 – Spring 2008

Shrink Wrapping

•Generalizes leaf-routine optimization for non leaves

•Moves prologue and epilogue code along CFG within a procedure

•Uses anticipability and availability

27 CS 671 – Spring 2008

Interprocedural Constant Propagation

Can be:• Site independent – same constant in every

invocation• Site specific – same constant every invocation from

one particular call site

28 CS 671 – Spring 2008

Interprocedural Optimizations

• Interprocedural analysis can guide inlining• Site-independent constant prop analysis can

optimize procedure bodies• Site-dependent constant prop can clone

procedure body copies to optimize for a call site• Tailor the calling conventions for a specific call

site• Can use interprocedural dataflow information

to improve intraprocedural data-flow for procedure entries, exits, calls, returns.• Procedure specialization can drive array

bounds optimizations

29 CS 671 – Spring 2008

Interprocedural Register Allocation

Link Time or Compile Time• Mainly extensions to graph coloring• Involves interprocedural live variable analysis• Tries to minimize save/restore overheads• Procedures in different subtrees of the call graph

can share registers

main

a

c

b

d

e

f

g

30 CS 671 – Spring 2008

Aggregation of Global References

• Link-time optimization

• Collect global data into an area that can be referenced by short offsets

• Avoids need to calculate “high order” bits

• Reserve global pointer (gp) register during compilation

• Extension: Sort the global objects smallest to largest to maximize the number of objects accessible by the gp

31 CS 671 – Spring 2008

IP Optimization Challenges

Name scoping – which modules are affected by changes to global variables

Recompilaton – determining when a change in one module requires recompilation of another

Linkage – shared objects and their effects on the modules that use them• See Mary Hall’s Ph.D. thesis (1991)

32 CS 671 – Spring 2008

Summary

Interprocedural optimizations are:• Challenging• Similar in many respects to intraprocedural

optimizations • Not thoroughly explored/proven/used

Next time• Test 2!