Advanced Compilers CMPSCI 710 Spring 2003 Interprocedural Analysis

Advanced Compilers CMPSCI 710 Spring 2003 Interprocedural Analysis Emery Berger University of Massachusetts, Amherst UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science

Topics n n Up to now n Intraprocedural analyses n Dataflow analyses n Def. Use, SSA n Register Allocation n Scheduling n Just for individual procedures Today: Interprocedural analysis n across/between procedures n Why? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 2

Aliasing n Formals and/or globals may be aliased n n n Two names point to same location Only form of aliasing for Java, Fortran At procedure call n Globals may be modified or used n Actual args may be modified or used UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 3

Aliasing Examples, I n Need alias analysis to do: n Instruction scheduling n Register allocation UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 4

Aliasing Examples, II n Need alias analysis to do: n Dead code elimination n Code motion UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 5

Alias Examples, III n n Need alias analysis to do: n Constant propagation To perform alias analysis, we need… UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 6

Interprocedural Analysis n Goals n n Enable standard optimizations even with procedure calls Reduce call overhead for procedures Enable optimizations not possible for single procedures Optimizations Register allocation n Loop transformations n CSE, etc. UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science n 7

Problems with Interprocedural Analysis n Not without drawbacks n Whole-program analysis n n What about libraries? Separate compilation requires recompilation analysis [Burke & Torczon 93] Expensive Doesn’t scale well, or worse n Some problems intractable n e. g. , Flow-sensitive kill UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 8

Analysis Sensitivity n n Flow-insensitive n What may happen (on at least one path) n Linear-time Flow-sensitive n Consider control flow (what must happen) n Iterative data-flow: possibly exponential Context-insensitive n Call treated the same regardless of caller n “Monovariant” analysis Context-sensitive n Reanalyze callee for each caller n “Polyvariant” analysis n More sensitivity ) more accuracy, but more expense UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 9

Context Sensitivity n n n Reanalyze callee as if procedure was inlined Too expensive in space & time n Recursion? Approximate context sensitivity: n Reanalyze callee for k levels of calling context UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 10

Summary Information n Another approach: summarize each procedure n Effect/result of called procedure for callers n Effect/input of callers for called procedure n Store in database for use by later optimization pass Pros: + Concise + Fast + Practical: separate compilation Cons: - Imprecise UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 11

Two Types of Information n Track info that flows into procedures n “Propagation problems”, e. g. : n n n which formals are constant? which formals are aliased to globals? Track info that flows out of procedures n “Side effect problems”, e. g. : n n n which globals defined/used by procedure? which locals defined/used by procedure? Which actual parameters defined by procedure? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 12

Propagation Summaries: Examples n MAY-ALIAS n n MUST-ALIAS n n Formals that may be aliased to globals Formals definitely aliased to globals CONSTANT n Formals that are definitely constant UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 13

Side-Effect Summaries: Examples n MOD n n REF n n Variables possibly modified (defined) by procedure call Variables possibly referenced (used) by procedure KILL n Variables that are definitely killed in procedure UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 14

Computing Summaries n Bottom-up (MOD, REF, KILL) n n Top-down (MAY-ALIAS) n n Summarizes effect of call Summarizes information about caller Bi-directional (AVAIL, CONSTANT) n Info to/from caller & callee UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 15

Implementing IPA: The Call Graph n Represent procedure call relationship by call graph n n n G = (V, E, start) Each procedure is unique vertex Call site = edge between caller & callee n n n (u, v) = call from u to v Can label with source line Cycles represent recursion UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 16

Call Graph Example UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 17

Side-Effect Summarization n At procedure boundaries: n n Translate formal args to actuals at call site Compute: n n GMOD, GREF = procedure side effects MOD, REF = effects at call site n Possibly specific to call UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 18

Side-Effect Summary Example UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 19

Alternatives to IPA: Inlining n Inlining: replace call with procedure body n Pros + Exposes context & side effects + Simple n Cons - Code bloat (bad for caches, branch predictor) Can’t decide statically for OOPs Library source? Recursion? How do we decide when to inline? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 20

Alternatives to IPA: Cloning n n n Cloning: customize procedure for certain call sites Partition call sites to procedure p into equivalence classes n e. g. , {{call 3, call 1}, {call 4}} Equivalence based on optimization n Constant propagation: partition based on parameter value UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 21

Cloning n Pros + + n Compromise between inlining & IPA Less code bloat compared to inlining No problem with recursion Improves optimization potential (compared to IPA) Cons - Some code bloat (compared to IPA) - Doesn’t eliminate need for IPA - How do we partition call sites? UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 22

Conclusion n Interprocedural analysis n Difficult but expensive n n n Useful for many optimizations IPA and cloning likely to become more important n n Need source code, recompilation analysis Trade-offs for precision & speed/space Better than inlining Java: many small procedures Next time: n Homework 2 review UNIVERSITY OF MASSACHUSETTS, AMHERST • Department of Computer Science 23