A Simple, Verified Validator for Software Pipelining (verification pearl) Jean-Baptiste Tristan Xavier Leroy INRIA Paris-Rocquencourt INRIA Paris-Rocquencourt B.P. 105, 78153 Le Chesnay, France B.P. 105, 78153 Le Chesnay, France [email protected] [email protected] Abstract unrolling the loop then performing acyclic scheduling. Software Software pipelining is a loop optimization that overlaps the execu- pipelining is implemented in many production compilers and de- tion of several iterations of a loop to expose more instruction-level scribed in several compiler textbooks [1, section 10.5] [2, chapter parallelism. It can result in first-class performance characteristics, 20] [16, section 17.4]. In the words of the rather dramatic quote but at the cost of significant obfuscation of the code, making this above, “truly desperate” programmers occasionally perform soft- optimization difficult to test and debug. In this paper, we present a ware pipelining by hand, especially on multimedia and signal pro- translation validation algorithm that uses symbolic evaluation to de- cessing kernels. tect semantics discrepancies between a loop and its pipelined ver- Starting in the 1980’s, many clever algorithms were designed sion. Our algorithm can be implemented simply and efficiently, is to produce efficient software pipelines and implement them either provably sound, and appears to be complete with respect to most on stock hardware or by taking advantage of special features such modulo scheduling algorithms. A conclusion of this case study is as those of the IA64 architecture. In this paper, we are not con- that it is possible and effective to use symbolic evaluation to reason cerned about the performance characteristics of these algorithms, about loop transformations. but rather about their semantic correctness: does the generated, software-pipelined code compute the same results as the original Categories and Subject Descriptors D.2.4 [Software Engineer- code? As with all advanced compiler optimizations, and perhaps ing]: Software/Program Verification - Correctness proofs; D.3.4 even more so here, mistakes happen in the design and implementa- [Programming Languages]: Processors - Optimization tion of software pipelining algorithms, causing incorrect code to be General Terms Languages, Verification, Algorithms generated from correct source programs. The extensive code rear- rangement performed by software pipelining makes visual inspec- Keywords Software pipelining, translation validation, symbolic tion of the generated code ineffective; the additional boundary con- evaluation, verified compilers ditions introduced make exhaustive testing difficult. For instance, after describing a particularly thorny issue, Rau et al. [23] note that 1. Introduction The authors are indirectly aware of at least one computer There is one last technique in the arsenal of the software manufacturer whose attempts to implement modulo schedul- optimizer that may be used to make most machines run at ing, without having understood this issue, resulted in a com- tip top speed. It can also lead to severe code bloat and may piler which generated incorrect code. make for almost unreadable code, so should be considered the last refuge of the truly desperate. However, its perfor- Translation validation is a systematic technique to detect (at mance characteristics are in many cases unmatched by any compile-time) semantic discrepancies introduced by buggy com- other approach, so we cover it here. It is called software piler passes or desperate programmers who optimize by hand, and pipelining [. ] to build confidence in the result of a compilation run or manual Apple Developer Connection1 optimization session. In this approach, the programs before and after optimization are fed to a validator (a piece of software dis- Software pipelining is an advanced instruction scheduling opti- tinct from the optimizer), which tries to establish that the two pro- mization that exposes considerable instruction-level parallelism by grams are semantically equivalent; if it fails, compilation is aborted overlapping the execution of several iterations of a loop. It pro- or continues with the unoptimized code, discarding the incorrect duces smaller code and eliminates more pipeline stalls than merely optimization. As invented by Pnueli et al. [20], translation valida- tion proceeds by generation of verification conditions followed by 1 http://developer.apple.com/hardwaredrivers/ve/ model-checking or automated theorem proving [19, 29, 28, 3, 8]. software pipelining.html An alternate approach, less general but less costly in validation time, relies on combinations of symbolic evaluation and static anal- ysis [18, 24, 6, 26, 27]. The VCGen/theorem-proving approach was applied to software pipelining by Leviathan and Pnueli [14]. It was Permission to make digital or hard copies of all or part of this work for personal or long believed that symbolic evaluation with static analyses was too classroom use is granted without fee provided that copies are not made or distributed weak to validate aggressive loop optimizations such as software for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute pipelining. to lists, requires prior specific permission and/or a fee. In this paper, we present a novel translation validation algo- POPL’10, January 17–23, 2010, Madrid, Spain. rithm for software pipelining, based on symbolic evaluation. This Copyright c 2010 ACM 978-1-60558-479-9/10/01. $10.00 algorithm is surprisingly simple, proved to be sound (most of the Original loop body B: Prolog P: Steady state S: Epilogue E: x := load(float64, p); p1 := p; store(float64, p1, y); store(float64, p1, y); y := x * c; p2 := p; p1 := p2 + 8; y := x2 * c; store(float64, p, y); x1 := x; y := x2 * c; store(float64, p2, y); p := p + 8; x2 := x; x1 := load(float64, p1); x := x2; i := i + 1; x1 := load(float64, p1); store(float64, p2, y); p := p2; p2 := p1 + 8; p2 := p1 + 8; x2 := load(float64, p2); y := x1 * c; y := x1 * c; x2 := load(float64, p2); i := i + 2; i := i + 2; Figure 1. An example of software pipelining proof was mechanized using the Coq proof assistant), and infor- • E is the loop epilog: a sequence of instructions that drains the mally argued to be complete with respect to a wide class of soft- pipeline, finishing the computations that are still in progress at ware pipelining optimizations. the end of the steady state. The formal verification of a validator consists in mechanically • µ is the minimum number of iterations that must be performed proving that if it returns true, its two input programs do behave to be able to use the pipelined loop. identically at run time. This is a worthwhile endeavor for two rea- sons. First, it brings additional confidence that the results of vali- • δ is the amount of unrolling that has been performed on the dation are trustworthy. Second, it provides an attractive alternative steady state. In other words, one iteration of S corresponds to δ to formally verifying the soundness of the optimization algorithm iterations of the original loop B. itself: the validator is often smaller and easier to verify than the op- The prolog P is assumed to increment the loop index i by µ; the timization it validates [26]. The validation algorithm presented in steady state S, by δ; and the epilogue E, not at all. this paper grew out of the desire to add a software pipelining pass The software pipelining algorithms that we have in mind here to the CompCert high-assurance C compiler [11]. Its formal veri- are combinations of modulo scheduling [22, 7, 15, 23, 4] fol- fication in Coq is not entirely complete at the time of this writing, lowed by modulo variable expansion [10]. However, the presenta- but appears within reach given the simplicity of the algorithm. tion above seems general enough to accommodate other scheduling The remainder of this paper is organized as follows. Section 2 algorithms. recalls the effect of software pipelining on the shape of loops. Sec- Figure 1 illustrates one run of a software pipeliner. The schedule tion 3 outlines the basic principle of our validator. Section 4 defines obtained by modulo scheduling performs, at each iteration, the ith the flavor of symbolic evaluation that it uses. Section 5 presents the th validation algorithm. Its soundness is proved in section 6; its com- store and increment of p, the (i+1) multiplication by c, and the th pleteness is discussed in section 7. The experience gained on a pro- (i + 2) load. To avoid read-after-write hazards, modulo variable totype implementation is discussed in section 8. Section 9 discusses expansion was performed, unrolling the schedule by a factor of 2, related work, and is followed by conclusions and perspectives in and replacing variables p and x by two variables each, p1/p2 and section 10. x1/x2, which are defined in an alternating manner. These pairs of variables are initialized from p and x in the prolog; the epilogue sets p and x back to their final values. The unrolling factor δ is 2. Software pipelining therefore 2. Likewise, the minimum number of iterations is µ = 2. From the bird’s eye, software pipelining is performed in three steps. Step 3 Finally, the original loop is replaced by the following Step 1 Select one inner loop for pipelining. Like in most previous pseudo-code: work, we restrict ourselves to simple counted loops of the form i := 0; i := 0; if (N ≥ µ) f while (i < N) f B g M := ((N − µ)/δ) × δ + µ; We assume that the loop bound N is a loop-invariant variable, P that the loop body B is a basic block (no conditional branches, no while (i < M) f S g function calls), and that the loop index i is incremented exactly E once in B.