Post Link-Time Optimization on the Intel IA-32 Architecture£ Benjamin William Schwarz Abstract Post link-time optimization of executables has been investigated by several projects in recent years. These opti- mization systems have targeted RISC architectures like the Compaq Alpha, and have shown that there is considerable room for improvement in compiler-generated code. Classical compiler optimizations like constant propagation, func- tion inlining, and dead code elimination have been shown to be relatively effective when applied at link-time. In addition, other optimizations—such as value specialization, load/store forwarding, and code layout—that are not typ- ically carried out at compile-time can also be used effectively. Unfortunately, many of the analyses introduced by other systems are insufficient when carried out on a CISC machine (e.g. the x86). We describe PLTO, a link-time optimizer for the Intel IA-32 architecture, that addresses the inherent difficulties in static analysis of binaries compiled for a CISC architecture. Many of the challenging issues stem from intrinsic characteristics of the architecture, such as the small register set which lends way to a heavy reliance on using the runtime stack. This paper discusses many analyses and optimizations used by PLTO, and we show the performance gains our system is able to achieve over compiler-generated, heavily-optimized executables. £ This research was supported by the National Science Foundation through grants ACR-9720738 and CCR-0113633. 1 Contents 1 Introduction 4 2 PLTO : A Pentium Link-Time Optimizer 4 2.1 RequirementsandAssumptions . ............... 5 3 Disassembly and Control Flow Analysis 6 3.1 PhaseFlowchart.................................. ............ 6 3.2 Pre-processingforELFExecutables . .................. 6 3.3 Disassembly..................................... ........... 6 3.3.1 Position-IndependentCode. .............. 7 3.3.2 DisassemblywithLinearSweep . ............. 8 3.3.3 DisassemblywithRecursiveTraversal . ................. 8 3.3.4 ExtendingLinearSweep . ........... 10 3.3.5 Combining Linear Sweep and Recursive Traversal: A HybridAlgorithm. 11 3.3.6 ExperimentalResults. ............ 12 3.4 IssuesinControlFlowAnalysis . ................ 12 4 Analyses 14 4.1 StackAnalysis ................................... ........... 14 4.1.1 AlgorithmandEquations. ............ 15 4.1.2 InterproceduralConsiderations. ................. 15 4.2 UseandKill-DepthAnalyses. ............... 16 4.3 LivenessAnalyses................................ ............. 18 4.3.1 StackLivenessAnalysis . ............ 18 4.3.2 RegisterLivenessAnalysis. .............. 18 4.4 Analysis of the Optimization Potential of Code Fragments ....................... 20 4.4.1 On-DemandComputation . .......... 21 4.5 Instruction-CacheAnalysis . ................. 22 4.5.1 ANon-conservativemodel . ............ 23 4.5.2 AConservativeModel . .......... 24 4.5.3 Comparison.................................... ........ 25 5 Optimizations 25 5.1 ConstantPropagation . .............. 25 5.1.1 RegisterPropagation . ............ 26 5.1.2 AnalysisofPrecision. ............ 27 5.1.3 RepresentationIssues. ............. 27 5.2 FunctionInlining ................................ ............. 28 5.3 JumpTableSpecialization . ............... 29 5.4 Profile-GuidedCodeLayout . .............. 29 5.5 UnreachableCodeElimination . ................ 30 5.6 PeepholeOptimizations. ............... 31 6 Experimental Results 31 6.1 SPECint-95andSPECint-2000. ............... 31 6.2 FloatingPointBenchmarks . ............... 32 7 RelatedWork 33 2 8 Future Work and Open Problems 33 8.1 UsesforFreeRegisters . .............. 33 8.2 Memory Disambiguation: Insight into Indirect Loads and Stores .................... 33 8.3 Profiling........................................ .......... 34 8.4 DisassemblyRevisited . .............. 34 9 Conclusions 35 10 Acknowledgements 35 A Graphs for Inlining Models in SPECint95 38 B Disassembly Speeds with Linear, Recursive, and Hybrid 43 C Potential Benefit for Disambiguating Indirect Loads and Stores 44 D Inlining: Further Details 45 3 1 Introduction Modern compilers are good at code optimization; however, the analyses and optimizations they carry out are gener- ally restricted to individual functions. Even those which perform interprocedural optimizations do not have access to pre-compiled library routines. As a result, there is considerable room for improvement in the performance of code generated by conventional compilers, even with a high degree of compile-time optimizations. One solution is to per- form an additional phase of optimizations after the object modules have been linked. At this stage, the whole program (now available as machine code) and all statically-linked library code are available for inspection and modification. Although much semantic information is lost during compilation, there are still many opportunities to generate more efficient code than what the compiler has produced. One specific set of applications which has great potential to benefit from link-time optimization is scientific distributed-memory applications. It is common for scientific applications to run on large Beowulf clusters (Pentiums running Linux). These machines are cheap and easy to set up for distributed-memory computations, making them a favorite among people who run simulations. Often these programs make heavy use of pre-compiled libraries, such as MPI (the Message Passing Interface), to handle the delicate details of communication across the network. These message-passing libraries are written with the goal of being applicable to a wide range of programs, ranging from gravitational N-body simulations to adaptive grid computations. As such, they are very general in their functionality and implementation, and allow for a good deal of flexibility. This flexibility, however, often comes at the cost of inefficient code. Unfortunately, traditional link-time optimization systems have targeted RISC (Reduced Instruction Set Computer) architectures like the Compaq (formerly DEC) Alpha and the Sun SPARC. Little work has been done for CISC (Complex Instruction Set Computer) machines such as the x86 (e.g., Pentium II, Pentium III, Pentium Pro) in the post link-time optimization arena. Our contribution is a post link-time optimizer that operates on x86 executables compiled in the Executable and Linkable Format (ELF32), which is the binary file format used by the Linux operating system. Many of the analyses and optimizations carried out by our system are designed to deal with inherent difficulties of a CISC architecture. The dearth of registers and the strong reliance—by both compilers and the ISA (Instruction Set Architecture)—on using memory lend way to analyses that are very different from those designed for RISC machines. In particular, one cannot expect to see much improvement in performance by carrying out analyses across only registers. On a RISC architecture, however, it is perfectly feasible to ignore memory since the large register set enables most important operands to be stored in registers. Other characteristics of a CISC architecture—such as variable length instructions— complicate disassembly and re-assembly of the machine code instructions. The problem is made more challenging by the presence of data or jump tables embedded in sections of the executable that are typically reserved for code. Much of the remainder of this paper discusses our approach to overcoming the difficulties associated with the x86. The rest of the paper is organized as follows: Section 2 describes PLTO, our Pentium Link-Time Optimization system and discusses some requirements and assumptions made about the input. Section 3 examines the preprocessing required to deal with abnormalitiesin ELF binaries, and then explains the novelapproach PLTO uses for disassembling machine code. Analyses used by PLTO are detailed in Section 4. Section 5 explains how the analyses are used to guide optimizations throughout the system. We take a look at what optimizations result in the most performance improvements, and conclude with performance results in Section 6. Section 7 contains information about work related to binary rewriting, link-time optimization. Section 8 discusses future work and open problems, and our conclusions are presented in Section 9. 2 PLTO : A Pentium Link-Time Optimizer PLTO (Pentium Link-Time Optimizer) is a post link-time optimization system designed to modify IA-32 (i.e., x86) executables compiled under the Linux operating system. PLTO is a binary-rewriting tool—both its input and output are machine code. It is closely related to alto, a link-time optimizer for the Compaq Alpha [21]. The goal is to carry out aggressive whole-program optimization while still producing code that is functionally equivalent to the original. As such, all transformations performed by PLTO are conservative to ensure that correctness is retained. Like many highly-optimizing compilers and link-time optimizers, PLTO gathers execution profiles from training input before carrying out any optimizations. Currently, edge profiles are gathered to discover how many times control flows along each edge in the interprocedural control flow graph (ICFG). Basic block and instruction weights are derived from the edge profiles. Section 8 discusses some future directions in profiling of multiprocessor applications and context-sensitive profiling. 4 2.1 Requirements and Assumptions During the course of optimization and instrumentation, existing instructions inside the executable often change