Interprocedural OptimizationsCS 671April 8, 2008
CS 671 Spring 2008
Modularity is a VirtueDecomposing programs into procedures aids in readability and maintainabilityObject-oriented languages have pushed this trend even furtherIn a good design, procedures should be:An interfaceA black box
CS 671 Spring 2008
The CatchThis inhibits optimization! The compiler must assume:Called procedure may use or change any accessible variableProcedures caller provides arbitrary values as parametersInterprocedural optimizations use the calling relationships between procedures to optimize one or both of themExamples: 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
CS 671 Spring 2008
Interprocedural OptimizationsUntil now, weve only considered optimizations within a procedureExtending these approaches outside of the procedural space involves similar techniques:Performing interprocedural analysisControl flow Data flowUsing that information to perform interprocedural optimizations
CS 671 Spring 2008
Terminologyint a, e // globalsprocedure foo(var b, c) // formal argsb := cendprogram mainint d // localsfoo(a, d) // call site withend // actual argsIn procedure bodyformals and/or globals may be aliased (two names refer to same location)formals may have constant valueAt procedure callglobal vars may be modified or usedactual args may be modified or used
CS 671 Spring 2008
Call Graphs1 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 calleesReverse invocation order process procedure after its calleesfghij2,37121348
CS 671 Spring 2008
Partial Call Graphs1 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?fghi2,3748gij1213
CS 671 Spring 2008
Dealing with ProceduresAliasing 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?endSide 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?...
CS 671 Spring 2008
Interprocedural CompilationGoalsenable standard optimizations even in presence of procedure callsperform additional optimizations not possible for single proceduresreduce call overhead for proceduresIssues compilation speed re-engineering compiler separate compilation recompilation analysis libraries (no source code) dynamic shared objects (DSOs)
CS 671 Spring 2008
Interprocedural Analyses (IPA)
MAY-ALIAS may be aliasedMUST-ALIAS must be aliasedMOD may be modifiedREF may be referencedUSE may be used before killKILL must be killedAVAIL must be availableCONSTANT must be constant
CS 671 Spring 2008
Parameter BindingAt 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,bendprocedure foo (var c) // GMOD(foo)= bint d // GREF(foo)= a,bd := bbar(b) // MOD(bar) = bend // 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)
CS 671 Spring 2008
Direction of IPABottom-up summarizes call effect (MOD, REF, USE, KILL)procedure fooint 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 := eendfoo(1)
CS 671 Spring 2008
Interprocedural AnalysesFlow-insensitiveinterprocedural analysis summarizes all pathswhat may happen (happens on at least one path)Flow-sensitive interprocedural analysis indicates what must happen on all paths
CS 671 Spring 2008
Precision of IPAFlow-insensitive (MAY-ALIAS, MOD, REF)result not affected by control flow in procedureFlow-sensitive (USE, KILL, AVAIL)result affected by control flow in procedureABAB
CS 671 Spring 2008
Flow-Insensitive Aliases w/out PointersFor some languages, aliases arise only due to parameter passingWe can compute solutions efficiently by separating local/global portions of solutioncalculate where aliases are introduced (needs only local information)propagate aliasesReduce complexity further by finding global-formal and formal-formal aliases separatelyFlow-insensitive alias algorithmfind global-formal aliasesfind formal-formal aliasescombine
CS 671 Spring 2008
Alias AnalysisVariables x, y are aliased in procedure p if they may refer to the same memory location in palias pair MAY-ALIASAliases are introduced when the same variable is passed to two different locations in the same callthe formals become an alias pairprocedure bar(int c)foo(c,c)endprocedure foo(var a, b)... // in ALIASendThere is a visible (global) variable in both the caller and callee passed as an actual parameterglobal and formal become an alias pairint bfoo(b)procedure foo(var a)... // in ALIASend
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 aliasesp(a,a)procedure p(var b, c)q(b,c)endprocedure q(var d, e)... // in ALIASendWhen a variable aliased to a global is passed as a parameter to q,formal in q becomes aliased to globalint ap(a)procedure p(var b)q(b)endprocedure q(var c)... // in ALIASend
CS 671 Spring 2008
Alias Analysis (cont)Aliases are propagated when p calls q and when two actuals are aliased to the same globalthe formals become aliases
int ap(a)procedure p(var b)q(a,b)endprocedure q(var c, d)... // in ALIASend
CS 671 Spring 2008
Interprocedural OptimizationsTail call & tail recursion eliminationInliningLeaf-routine optimization & shrink wrappingInterprocedural constant propagationInterprocedural register allocationAggregation of global references
CS 671 Spring 2008
Tail Call & Tail Recursion EliminationTransformation that applies to callsReduce procedure-call overhead and enable additional optimizationsA call from procedure f() to procedure g() is a tail call if the only thing f() does, after g() returns to it, is itself returnThe call is tail recursive if f() and g() are the same
CS 671 Spring 2008
InliningReplaces calls to procedures with copies of their bodiesConverts calls from opaque objects to local codeExposes the effects of the called procedureExtends the compilation regionLanguage support: the inline attributeBut the compiler can decide per call-site, rather than per procedure
CS 671 Spring 2008
Inlining DecisionsMust be based on Heuristics, orProfile informationConsiderationsThe 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
CS 671 Spring 2008
An Interesting ExperimentCooper, Hall, Torczon (92)Integrated 44% of call sitesReduced dynamic calls by 98%8% performance degradation on MIPS R2000!
Suspect: Cache effects or register pressure in a critical loopCulprit: Fortran 77 conventions (assumes no aliasing on procedure entry)
CS 671 Spring 2008
Leaf-Routine OptimizationLeaf routineA procedure that is a leaf in the call graphIt calls no other proceduresLeaf routine optimizationSimplifies the way parameters are passed to a leaf routineRemoves much of the procedure prologue and epilogueDepends on the calling convention and temporary storage requirementsHow many procedures are leaf routines? (Hint: think of a binary tree)
CS 671 Spring 2008
Leaf-Routine OptimizationDetermine amount of storage (registers and stack space) requiredIf register usage is less than caller-save and scratch registers use them exclusivelyIf no stack space required, delete stack preparation codeIf procedure is small, instead consider inlining
CS 671 Spring 2008
Shrink WrappingGeneralizes leaf-routine optimization for non leavesMoves prologue and epilogue code along CFG within a procedureUses anticipability and availability
CS 671 Spring 2008
Interprocedural Constant PropagationCan be:Site independent same constant in every invocationSite specific same constant every invocation from one particular call site
CS 671 Spring 2008
Interprocedural OptimizationsInterprocedural analysis can guide inliningSite-independent constant prop analysis can optimize procedure bodiesSite-dependent constant prop can clone procedure body copies to optimize for a call siteTailor the calling conventions for a specific call siteCan use interprocedural dataflow information to improve intraprocedural data-flow for procedure entries, exits, calls, returns.Procedure specialization can drive array bounds optimizations
CS 671 Spring 2008
Interprocedural Register AllocationLink Time or Compile TimeMainly extensions to graph coloringInvolves interprocedural live variable analysisTries to minimize save/restore overheadsProcedures in different subtrees of the call graph can share registersmainacbdefg
CS 671 Spring 2008
Aggregation of Global ReferencesLink-time optimizationCollect global data into an area that can be referenced by short offsetsAvoids need to calculate high order bitsReserve global pointer (gp) register during compilationExtension: Sort the global objects smallest
