1. Interprocedural Optimizations CS 671 April 8, 2008

2. 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. 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. 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. Terminology • int a, e // globals • procedure foo(var b, c) // formal args • b := c • end • program main • int d // locals • foo(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. 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 { } f 2,3 4 8 g h 7 12 i j 13 Invocation order – process procedure before its callees Reverse invocation order – process procedure after its callees

7. 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 2,3 4 8 g h g 7 12 i i j 13

8. Dealing with Procedures • Aliasing example int a foo(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 := 1 foo(a) // used/killed? b := a // what is b? • Constants example foo(1) ... procedure foo(a) if (a = 1) // what is a? ...

9. 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. 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. Parameter Binding • At procedure boundaries, we need to translate formal arguments of procedure to actual arguments of procedure at call site int a,b program main // MOD(foo) = b foo(b) // REF(foo) = a,b end procedure foo (var c) // GMOD(foo)= b int d // GREF(foo)= a,b d := b bar(b) // MOD(bar) = b end // REF(bar) = a procedure bar (var d) if (...) // GMOD(bar)= d d := a // GREF(bar)= a end GMOD, GREF = side effect of procedure • MOD, REF = effect at call site (perhaps specific to call)

12. Direction of IPA • Bottom-up – summarizes call effect (MOD, REF, USE, KILL) procedure foo int a bar(a) end • Top-down – summarizes info from caller (MAY-ALIAS) int a,b procedure foo(var int b, c) ... end foo(a,a) foo(a,b) • Bi-directional – info to/from caller/callee (AVAIL, CONST) int a,b,c,d procedure foo(e) a := b + c d := e end foo(1)

13. 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. 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 A B B

15. 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 • calculate where aliases are introduced (needs only local information) • propagate aliases • Reduce complexity further by finding global-formal and formal-formal aliases separately • Flow-insensitive alias algorithm • find global-formal aliases • find formal-formal aliases • combine

16. 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) end procedure foo(var a, b) ... // <a,b> in ALIAS end • 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 b foo(b) procedure foo(var a) ... // <a,b> in ALIAS end

17. 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) end procedure q(var d, e) ... // <d,e> in ALIAS end • When a variable aliased to a global is passed as a parameter to q, • formal in q becomes aliased to global int a p(a) procedure p(var b) q(b) end procedure q(var c) ... // <a,c> in ALIAS end

18. 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 a p(a) procedure p(var b) q(a,b) end procedure q(var c, d) ... // <c,d> in ALIAS end

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

20. 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. 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. 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. 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. 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. 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. Shrink Wrapping • Generalizes leaf-routine optimization for non leaves • Moves prologue and epilogue code along CFG within a procedure • Uses anticipability and availability

27. Interprocedural Constant Propagation • Can be: • Site independent – same constant in every invocation • Site specific – same constant every invocation from one particular call site

28. 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. 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 b e c d f g

30. 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. 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. Summary • Interprocedural optimizations are: • Challenging • Similar in many respects to intraprocedural optimizations • Not thoroughly explored/proven/used • Next time • Test 2!