1 / 59

Advanced Compiler Techniques

Advanced Compiler Techniques. Inter-procedural Analysis. LIU Xianhua School of EECS, Peking University. Topics. Up to now Intra- procedural analysis Dataflow analysis PRE Loops SSA Just for individual procedures Today: Inter- procedural analysis across/between procedures.

apria
Télécharger la présentation

Advanced Compiler Techniques

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Advanced Compiler Techniques Inter-procedural Analysis LIU Xianhua School of EECS, Peking University

  2. Topics • Up to now • Intra-procedural analysis • Dataflow analysis • PRE • Loops • SSA • Just for individual procedures • Today: Inter-procedural analysis • across/between procedures “Advanced Compiler Techniques”

  3. 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 “Advanced Compiler Techniques”

  4. 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 “Advanced Compiler Techniques”

  5. Recall • Function calls can affect our points-to sets p1 = &x; p2 = &p1; ... foo(); • Be conservative • – Lose a lot of information “Advanced Compiler Techniques”

  6. Applications of IPA • Virtual method invocation • Pointer alias analysis • Parallelization • Detection software errors and vulnerabilities • SQL injection • Buffer overflow analysis & protection “Advanced Compiler Techniques”

  7. Basic Concepts • Procedure (Function ) • Caller/Callee • Call Site • Call Graph • Call Context • Call Strings • Formal Arguments • Actual Arguments “Advanced Compiler Techniques”

  8. Terminology Goal • – Avoid making overly conservative assumptions about the effects of procedures and the state at call sites 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 “Advanced Compiler Techniques”

  9. Interprocedural Analysis vs.InterproceduralOptimization • Interprocedural analysis • Gather information across multiple procedures • (typically across the entire program) • Can use this information to improve intraproceduralanalysis and optimization (e.g., CSE) • Interprocedural optimizations • Optimizations that involve multiple procedures e.g., Inlining, procedure cloning, interprocedural register allocation • Optimizations that use interprocedural analysis “Advanced Compiler Techniques”

  10. The Call Graph • Represent procedure call relationshipby call graph • G = (V,E,start) • Each procedure is a unique vertex • Call site = edge between caller & callee • (u,v) = call from u to v (u may call v) • Can label with source line • Cycles represent recursion “Advanced Compiler Techniques”

  11. Call Graph “Advanced Compiler Techniques”

  12. Super Graph “Advanced Compiler Techniques”

  13. Validity of InterproceduralControl Flow Paths “Advanced Compiler Techniques”

  14. Safety, Precision, and Efficiencyof Data Flow Analysis • Data flow analysis uses static representation of programs to compute summary information along paths • Ensuring Safety. All valid paths must be covered • Ensuring Precision . Only valid paths should be covered. • Ensuring Efficiency. Only relevant valid paths should be covered. A path which represents legal control flow A path which yields information that affects the summary information Subject to merging data flow values at shared program points without creating invalid paths “Advanced Compiler Techniques”

  15. Flow and Context Sensitivity • Flow sensitive analysis: • Considers intraprocedurally valid paths • Context sensitive analysis: • Considers interprocedurally valid paths • For maximum statically attainable precision , analysis must be both flow and context sensitive. “Advanced Compiler Techniques”

  16. Context Sensitivity inInterproceduralAnalysis “Advanced Compiler Techniques”

  17. Example of Context Sensitivity “Advanced Compiler Techniques”

  18. Staircase Diagrams ofInterprocedurallyValid Paths “You can descend only as much as you have ascended!” Every descending step must match a corresponding ascending step. “Advanced Compiler Techniques”

  19. Context Sensitivity inPresence of Recursion • For a path from u tov, g must be applied exactly the same number of times as f . • For a prefix of the above path, g can be applied only at most as many times as f . “Advanced Compiler Techniques”

  20. Staircase Diagrams ofInterprocedurallyValid Paths “Advanced Compiler Techniques”

  21. Interprocedural Analysis • Goals • Enable standard optimizations even with procedure calls • Reduce call overhead for procedures • Enable optimizations not possible for single procedures • Optimizations • Register allocation • Loop transformations • CSE, etc. “Advanced Compiler Techniques”

  22. Analysis Sensitivity • Flow-insensitive • What may happen (on at least one path) • Linear-time • Flow-sensitive • Consider control flow (what must happen) • Iterative data-flow: possibly exponential • Context-insensitive • Call treated the same regardless of caller • “Monovariant” analysis • Context-sensitive • Reanalyze callee for each caller • “Polyvariant” analysis • Path-sensitive vs. path-insensitive • Computes one answer for every execution path • Subsumes flow-sensitivity • Extremely expensive More sensitivity  More accuracy, but more expensive “Advanced Compiler Techniques”

  23. Increasing Precision inData Flow Analysis actually, only caller sensitive “Advanced Compiler Techniques”

  24. Precision of IPA • Flow-insensitive • result not affected by control flow in procedure • Flow-sensitive • result affected by control flow in procedure A A B B “Advanced Compiler Techniques”

  25. Context Sensitivity a = id(3); b = id(4); • Re-analyze callee as if procedure was inlined • Too expensive in space & time • Recursion? • Approximate context sensitivity: • Reanalyze callee for k levels of calling context 4 3 id(x) { return x; } a = min(3, 4); s = min(“aardvark”, “vacuum”); ints strings min(x, y) { if (x <= y) return x; else return y; } “Advanced Compiler Techniques”

  26. Path Sensitivity • 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 “Advanced Compiler Techniques”

  27. Key Challenges for Interprocedural Analysis • Compilation time, memory • Key problem: scalability to large programs • Dominated by analysis time/memory • Flow-sensitive analysis: bottleneck often memory, not time  Often limited to fast but impreciseanalysis • Multiple calling environments Different calls to P() have different properties: • Known constants • Aliases • Surrounding execution context (e.g., enclosing loops) • Function pointer arguments • Frequency of the call • Recursion “Advanced Compiler Techniques”

  28. 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 “Advanced Compiler Techniques”

  29. Middle Ground: Use Call Graph andCompute Summaries • Goal • Represent procedure • Call relationships • Definition • If program P consists of n procedures: p1, . . ., pn • Static call graph of P is GP = (N,S,E,r) • −N = {p1, . . ., pn} • −S = {call-site labels} • −E ⊆ N × N × S • −r ∈ N is start node “Advanced Compiler Techniques”

  30. Summary Information • Compute summary information for each procedure Summarize effect of called procedure for callers Summarize effect of callers for called procedure • Store summaries in database Use later when optimizing procedures • Pros +Concise +Can be fast to compute and use +Separate compilation practical • Cons – Imprecise if only have one summary per procedure “Advanced Compiler Techniques”

  31. Two Types of Information • Track info that flows into procedures • “Propagation problems”, e.g.: • which formals are constant? • which formals are aliased to globals? • Track info that flows out of procedures • “Side effect problems”, e.g.: • which globals defined/used by procedure? • which locals defined/used by procedure? • Which actual parameters defined by procedure? proc(x, y) { . . . } “Advanced Compiler Techniques”

  32. Propagation Summaries: Examples • MAY-ALIAS • Formals that may be aliased to globals • MUST-ALIAS • Formals definitely aliased to globals • CONSTANT • Formals that are definitely constant “Advanced Compiler Techniques”

  33. Side-Effect Summaries: Examples • MOD • Variables possibly modified (defined) by procedure call • REF • Variables possibly referenced (used) by procedure • KILL • Variables that are definitely killed in procedure “Advanced Compiler Techniques”

  34. Computing Summaries • Bottom-up (MOD, REF, KILL) • Summarizes call effects • Top-down (MAY-ALIAS) • Summarizes information about caller • Bi-directional (AVAIL, CONSTANT) • Info to/from caller & callee “Advanced Compiler Techniques”

  35. Side-Effect Summarization • At procedure boundaries: • Translate formal args to actuals at call site • Compute: • GMOD, GREF = procedure side effects • MOD, REF = effects at call site • Possibly specific to call “Advanced Compiler Techniques”

  36. Parameter Binding • At procedure boundaries, we need to translate formal arguments of procedure to actual arguments of procedure at call site inta,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 “Advanced Compiler Techniques”

  37. Constructing Summary Flow Functions Iteratively Termination is possible only if all function compositions and confluences can be reduced to a finite set of functions “Advanced Compiler Techniques”

  38. An Example of InterproceduralLivenessAnalysis “Advanced Compiler Techniques”

  39. An Example of InterproceduralLivenessAnalysis “Advanced Compiler Techniques”

  40. An Example of InterproceduralLivenessAnalysis “Advanced Compiler Techniques”

  41. An Example of InterproceduralLivenessAnalysis “Advanced Compiler Techniques”

  42. An Example of InterproceduralLivenessAnalysis “Advanced Compiler Techniques”

  43. An Example of InterproceduralLivenessAnalysis e ∈InSpbut e ∉Inc1 “Advanced Compiler Techniques”

  44. Interprocedural Validity andCalling Contexts “You can descend only as much as you have ascended!” Every descending step must match a corresponding ascending step. Calling context is represented by the remaining descending steps. “Advanced Compiler Techniques”

  45. Available Expressions Analysis Using Call Strings Approach inta, b, t; void p() { if (a == 0) { a = a-1; p(); t = a∗b; } } YES! Is a ∗ b available? “Advanced Compiler Techniques”

  46. Available Expressions Analysis Using Call Strings Approach “Advanced Compiler Techniques”

  47. Alternatives to IPA: 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 “Advanced Compiler Techniques”

  48. 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 “Advanced Compiler Techniques”

  49. 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 “Advanced Compiler Techniques”

  50. Study on Real Compilers What do you expect? V.S. Cooper, Hall, Torczon (92) • Eight Programs, five compilers, five processors • Eliminated 99% of dynamic calls in 5 of the programs • Measured speed of original vs. transformed code “Advanced Compiler Techniques”

More Related