Download presentation
Presentation is loading. Please wait.
1
Contification Using Dominators
Matthew Fluet Cornell University Stephen Weeks InterTrust STAR Lab
2
interprocedural intraprocedural
Motivation use traditional optimizations in functional-language compilers traditional optimizations require intraprocedural control-flow information in functional languages, most control-flow information is interprocedural contification: a technique for turning function calls into local control-flow transfers interprocedural intraprocedural Traditional optimizations: common-subexpression elimination, loop-invariant code motion Contification: coined term – defined on a CPS-like IL, where functions are turned into continuations a technique for turning function calls into local control-flow transfers in particular, recursive functions used to implement loops should be recognizable as loops
3
An Example main() k(z) ... l() k(even(3)) ret(false) even(y-1) odd(y)
if y = 0 even(x) if x = 0 ret(true) odd(x-1) k main() k(z) ... l() k(even(3)) k(false) k(true) even(3) ret(false) even(y-1) odd(y) if y = 0 even(x) if x = 0 ret(true) odd(x-1) k even(x) if x = 0 ret(true) odd(x-1) k Tail vs. Non-tail calls k represents a continuation Different from inlining: no substitution of actual arguments for function parameters no duplication of code ret(false) even(y-1) odd(y) if y = 0
4
MLton a whole-program optimizing compiler for Standard ML SML
defunctorize polymorphic, higher-order IL monomorphise simply-typed, higher-order IL Contification occurs during the optimizing cycle on a simply-typed, first-order IL. closure convert optimize simply-typed, first-order IL generate code native x86
5
Contification when a function g is contified within a function f
intraprocedural control-flow is exposed g will share the same stack frame as f invocations of g can be optimized goal: contify as many functions as possible components of contification analysis: what functions are contified and where transformation: single-pass rewrite of the program turns function calls into local control-flow transfer, enabling subsequent optimizations g will share the same environment as f; hence, can share the same stack frame invocations of g can be optimized as local control-flow transfers, where live variables can be passed in registers, rather than as function calls, where standard calling conventions must be followed
6
Contification Analysis I
represent a program by its call graph functions m, f, g, h and continuations k, l a distinguished main function m nontail calls tail calls f g k f g m f g k multiple edges can exist between nodes, corresponding to multiple calls
7
Contification Analysis II
an analysis maps functions to abstract return locations Return = {?} Cont Func A Analysis = Func Return A(g) = f g always returns to function f g is contified in the body of f A(g) = k g always returns to continuation k g is contified where k is defined and g is transformed to transfer control to k A(g) = ? g is not contified in the transformed program Return == almost like a squashed-powerset domain: elements from Cont and Func correspond to singleton sets of return locations, ? stands for everything else ? – is a distinguished element indicating either unknown or multiple return points the sets Cont and Func are sets of syntactic labels contified moving code for one function into another function
8
Safety safety ensures a well-defined and correct transformation
an analysis A is safe if the following hold A(m) = ? if then A(g) {k, ?} if then A(g) {f, A(f), ?} f g k the main function must not be contified a non-tail call must return to it’s continuation; the rewrite of a function contified at a continuation requires transforming returns to jumps to the continuation a tail call must return to it’s caller; hence, it must be contified either in it’s caller or at the same place as it’s caller f g
9
The Acall and Acont Analyses
Acall – a simple syntactic analysis Acont – a least fixed-point analysis [Reppy 2001] l ? f l ? k1 k2 f g1 g2 h1 m h2 l Two safe analyses: Acall – original contification analysis used in MLton Acont – based on a similar analysis used in the Moby programming language Described in detail, with proofs of safety, in the paper. Clear that g1, g2, and h1 all return to function f, but neither analysis contifies h1
10
Node = Return = {?} Cont Func
The Adom Analysis I build a directed graph G, similar to the call graph Node = Return = {?} Cont Func each edge (l, f) indicates that f returns to location l if l = ?, then f has no return location k1 k2 f g1 g2 h1 m h2 l Call Graph ? Graph G the directed graph G is similar to the call graph, but contains the return information needed for contification each edge in the call graph corresponds to an edge in the graph G additional edges from root The dominator analysis is defined using the dominator tree of G. A node x dominates in a node y in a graph if every path from the root to y goes through x For example, f dominates h1.
11
The Adom Analysis II l build the dominator tree D of G
l dominates f if f always returns to l in any execution of the program define Adom(f) to be the dominator of f closest to ? if the immediate dominator of f is ?, then Adom(f) = ? l ? f f g1 g2 h1 ? h2 k1 l k2 m Dominator Tree D k1 k2 f g1 g2 h1 m h2 l Call Graph In the dominator tree, the parent of a node is it’s immediate dominator.
12
The Adom Analysis III Theorem: Adom is safe. Theorem: Adom is maximal.
for all safe analyses B and all functions f, if B(f) ?, then Adom(f) ? How do we know that we can’t construct a call graph with a contifiable function not contified by the Adom analysis? Definition of maximality captures notion of “contifying as many functions as possible.” For any given safe analysis, the Adom analysis contifies a superset of the functions contified by the safe analysis. Detailed proofs in the paper.
13
Compile-time Performance
three rounds … contification quiesces … - intervening optimizations may reveal new opportunities for optimizations (e.g., dead-code) - intervening optimizations include constant propagation, dead code elimination, common-subexpression elimination Function counts are normalized to the function count of the program with no contification transformation three rounds of contification in the optimizing cycle contification quiesces after two rounds contification takes less than 4% of total compile time typically less than one second, with a maximum of 13 seconds
14
Run-time Performance anomalies
Running times are normalized to the running time of the program with no contification transformation Running times are avg. of three runs. Acall is a simple analysis – only exposes simple control-flow Adom is more complicated – haven’t yet taken full advantage of optimizing the more complicated control-flow that can now appear in functions anomalies contification may disable size-based inlining MLton’s optimizer evolved around Acall
15
Conclusions a simple, yet general, framework for expressing contification analyses single transformation safety condition maximality criterion contification is efficient and improves running times Got MLton? You should.
17
Related Transformations
Local CPS conversion [Reppy 2001] analyzes a module in isolation operates over a higher-order IL escaping functions with unknown control-flow cause imprecision requires local CPS conversion to apply transformation Lambda dropping [Danvy and Schultz 2000] does not approximate the returns of a function does not change calls from tail to nontail, or vice versa Loop headers [Appel 1994] transformation local to a particular function relies on inlining to expose new control-flow
18
References A. W. Appel. Loop headers in -calculus or CPS. Lisp and Symbolic Computation, 7: , 1994. O. Danvy and U. P. Schultz. Lambda-dropping: Transforming recursive equations into programs with block structure. Theoretical Computer Science, 248(1-2): , 2000. J. Reppy. Local CPS conversion in a direct-style compiler. In Workshop on Continuations, pages 1-5, Jan
19
Comparison to Inlining
no substitution of actual arguments for function parameters no duplication of code k1 k2 f g1 m k g h
20
The Acall Analysis intuition: a function f has one return location if
there is exactly one call to f from outside its body; and there are only tail calls to f within its body a simple syntactic analysis original contification analysis used in MLton ? k f m g
21
But… m f g k h f, g, and h always return to continuation k
? f, g, and h always return to continuation k but, the call analysis fails to contify any of the functions
22
The Acont Analysis intuition: a function f returns to continuation k if all nontail calls to f use k; and all tail callers of f also return to k a least fixed point ties the recursion based on a similar analysis in Moby [Reppy 2001] fm f g k h ?
23
But… f g1 g2 k1 h k2 fm g1, g2, and h all return to function f
? ? g1, g2, and h all return to function f but, the call analysis fails to contify h and, the continuation analysis fails to contify any function
24
The Adom Analysis IV setting Adom(f) equal to the immediate dominator of f violates safety Adom(h1) = f {g3, A(g3), ?} = {g3, g2, ?} Call Graph k1 k2 f g1 g2 h1 m h2 l g3 Dominator Tree D Root
25
An Example I even(x) if x = 0 ret(true) odd(x-1)
Tail vs. Non-tail calls k represents a continuation Different from inlining: no substitution of actual arguments for function parameters no duplication of code
26
An Example II main() k(z) ... l() k(even(3)) even(x) if x = 0
ret(true) odd(x-1) k Tail vs. Non-tail calls k represents a continuation Different from inlining: no substitution of actual arguments for function parameters no duplication of code ret(false) even(y-1) odd(y) if y = 0
27
An Example III main() k(z) ... l() k(even(3)) ret(false) even(y-1)
odd(y) if y = 0 even(x) if x = 0 ret(true) odd(x-1) k Tail vs. Non-tail calls k represents a continuation Different from inlining: no substitution of actual arguments for function parameters no duplication of code
28
An Example IV ret(false) even(y-1) odd(y) if y = 0 even(x) if x = 0
ret(true) odd(x-1) k main() k(z) ... l() k(even(3)) k(false) k(true) even(3) Tail vs. Non-tail calls k represents a continuation Different from inlining: no substitution of actual arguments for function parameters no duplication of code
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.