Practical and effective higher-order optimizations

Abstract

Inlining is an optimization that replaces a call to a function with that function's body. This optimization not only reduces the overhead of a function call, but can expose additional optimization opportunities to the compiler, such as removing redundant operations or unused conditional branches. Another optimization, copy propagation, replaces a redundant copy of a still-live variable with the original. Copy propagation can reduce the total number of live variables, reducing register pressure and memory usage, and possibly eliminating redundant memory-to-memory copies. In practice, both of these optimizations are implemented in nearly every modern compiler.These two optimizations are practical to implement and effective in first-order languages, but in languages with lexically-scoped first-class functions (aka, closures), these optimizations are not available to code programmed in a higher-order style. With higherorder functions, the analysis challenge has been that the environment at the call site must be the same as at the closure capture location, up to the free variables, or the meaning of the program may change. Olin Shivers' 1991 dissertation called this family of optimizations Super-β and he proposed one analysis technique, called reflow, to support these optimizations. Unfortunately, reflow has proven too expensive to implement in practice. Because these higher-order optimizations are not available in functional-language compilers, programmers studiously avoid uses of higher-order values that cannot be optimized (particularly in compiler benchmarks).This paper provides the first practical and effective technique for Super-β (higher-order) inlining and copy propagation, which we call unchanged variable analysis. We show that this technique is practical by implementing it in the context of a real compiler for an ML-family language and showing that the required analyses have costs below 3% of the total compilation time. This technique's effectiveness is shown through a set of benchmarks and example programs, where this analysis exposes additional potential optimization sites. * Portions of this work were performed while the author was at the University of Chicago.[Copyright notice will appear here once 'preprint' option is removed.]

Compiling with Continuations and LLVM

“…We support the parallelism and concurrency features of PML by transformations on the AST and BOM representations that introduce explicit continuation binders [15,16,4,25]. The translation from BOM to CPS uses the Danvy-Filinski CPS transformation [7] and we perform several kinds of optimizations on the CPS IR [5,3]. The conversion from CPS to CFG uses a flat, safe-for-space, closure representation [6].…”

“…This technique is borrowed from the SML/NJ system; the spill limit is enforced by the compiler limiting the number of live variables at any control point and over-provisioning the spill area. 3 In short sequences, LLVM's code generator may introduce one or two additional spills, but by limiting the number of values early on, we effectively bound the number of register spills. LLVM's code generator will assign any register spills to frame locations starting from the bottom of the frame, offset from the stack pointer, so the shim preserves all C callee-saved registers at the top of the frame.…”

Control Flow Analysis for SF Combinator Calculus

“…From Γ, ϕ |= t l we have Γ, ϕ |= x l 1 , showing Condition 1. Expanding the constraints for Γ, ϕ |= t l further, we get: K l 2 0 ∈ Γ(l 2 ); hence Γ(l 1 ) ⊆ Γ(l 2 .K.0) and K l 2 1 ∈ Γ(l 3 ); thus Γ(l 2 .K.0) ⊆ Γ(l 4 ). Combining these gives Γ(l 1 ) ⊆ Γ(l 4 ), proving Condition 2.…”

“…0CFA [20] is a popular form of Control Flow Analysis. It is flow insensitive and context insensitive, but precise enough to be useful for many applications, including guiding compiler optimisations [17,2], providing autocompletion hints in IDEs and noninterference analysis [14]. It is perhaps the simplest static analysis that handles higher order functions, which are a staple of functional programming.…”

“…1 , @ (4,3) } Γ(6) = {S 6 0 } Γ(6.S.0) = {F 4 1 , @ (4,3) } Γ(6.S.1) = {F 1 1 , @ (1,0) } Γ(7) = {S 6 1 , @ (6,5) } Γ(8) = {S 6 2 , @ (7,2) } Γ(9) = {F 9 0 } Γ(10) = {F 10 0 } Γ(10.F.0) = {F 9 0 } Γ(10.F.1) = {S 6 2 , @ (7,2) } Γ(11) = {F 10 1 , @ (10,9) } Γ(12) = {F 12 0 } Γ(13) = {F 13 0 } Γ(13.F.0) = {F 12 0 } Γ(13.F.1) = {S 6 2 , @ (7,2) } Γ(13.F.3) = {S 6 2 , @ (7,2) } Γ(13.F.2) = {F 10 2 , @ (15.S.1,15.S.2) } Γ(14) = {F 13 1 @ (13,12) } Γ(15) = {S 15 0 } Γ(15.S.0) = {F 13 1 , @ (13,12) } Γ(15.S.1) = {F 10 1 , @ (10,9) } Γ(15.S.2) = {S 6 2 , @ (7,2) } Γ(15.S.3) = {S 6 2 , @ (15.S.L,15.S.R) , @ (7,2) } Γ(15.S.L) = {F 13 2 , @ (15.S.0,15.S.2) } Γ(16) = {S 15 1 , @ (15,14) } Γ(15.S.R) = {F 10 2 , @ (15.S.1,15.S.2) } Γ(17) = {S 15 2 , @ (16,11) } Γ(18) = {S 6 2 , @ (15.S.L,15.S.R) , @ (17,8) , @ (7,2) } ϕ(13) = true ϕ(15) = true Γ, ϕ |= (S 15 @ 16 (F 13 @ 14 F 12 )@ 17 (F 10 @ 11 F 9 ))@ 18 (S 6 @ 7 (F 4 @ 5 F 3 )@ 8 (F 1 @ 2 F 0 ))…”