Validating Software Pipelining Optimizations ∗ Raya Leviathan Amir Pnueli Dept. of Computer Science Dept. of Computer Science Weizmann Institute of Science Weizmann Institute of Science [email protected] [email protected] ABSTRACT of software systems. However, proving the correctness The paper presents a method for translation validation of the implementation written in a high level language of a specific optimization, software pipelining optimiza- is not sufficient. It should also be verified that what- tion, used to increase the instruction level parallelism in ever correctness has been achieved on the higher level EPIC type of architectures. Using a methodology as in is not impaired in the translation done by the compiler. [15] to establish simulation relation between source and But, formally verifying s full fledge optimizing compiler target based on computational induction, we describe is not feasible due to its size, evolution over time and an algorithm that automatically produces a set of decid- possibly, proprietary consideration. The translation val- able proof obligations. The paper also describes SPV, a idation approach offers an alternative to the verification prototype translation validator that automatically pro- of translators in general and of compilers in particular. duces verification conditions for software pipelining op- The efficacy of this approach were demonstrated by the timizations of the SGI Pro-64 compiler. These verifi- discovery of a bug in the Trimaran compiler, which may cation conditions are further checked automatically by produce an illegal memory access in the generated code the CVC [12] checker. (see [15],[14]). Modern architectures rely on the compiler to extract maximum performance and to ensure correct utilization Categories and Subject Descriptors of the processor. These requirements from the compiler D.3.4 [Programming Languages]: Processors|Com- are inevitable when considering compiler for an EPIC pilers, Optimization; D.2.4 [software Engineering]: (Explicitly Parallel Instruction Computation) proces- Software/Program Verification—Formal methods, Vali- sor. In this work we choose to address the problem dation; C.1.3 [Processor Architectures]: Other Ar- of formally verifying software pipelining optimization of chitecture Styles|Pipeline processors an EPIC processor. We extend the framework described in [15] and [14] to General Terms handle machine dependent optimizations, which have an important role for processors of the EPIC family. Here, Verification we describe our method to validate software pipelining optimization. The method is implemented for the code Keywords generator of the SGI Pro-64 compiler (to be called Pro- Compilers, Optimization, Pipeline processors, Verifica- 64), which produces code for the Intel-IA64 architec- tion, Translation Validation ture. Our tool, SPV, Software Pipeline Validation, runs fully automatically, starting with source and translated 1. INTRODUCTION programs and exiting with an either Valid or Invalid answer. There is a growing awareness of the importance of for- The formalization is based on transition semantics mally proving the correctness of safety-critical portion [9]. The correctness definition is based on refinement ∗This research was done as part of the SafeAir project relation between transition systems [3]. Our tool pro- of the Eurtopean Commission duces the proof obligations needed to establish the cor- rectness of the translation. These proof obligations be- long to the decidable logics of Pressburger Arithmetic, arrays and uninterpreted functions. As such, they can Permission to make digital or hard copies of all or part of this work for be checked by a fully automatic tool. For most of the ap- personal or classroom use is granted without fee provided that copies are plications reported here, we used the CVC (Cooperating not made or distributed for profit or commercial advantage and that copies Validity Checker ) tool [12] in order to dispatch the proof bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific obligations. The average run time to validate a transla- permission and/or a fee. tion which includes software pipelining optimization, CASES 2002, October 8–11, 2002, Grenoble, France. Copyright 2002 ACM 1-58113-575-0/02/0010 ...5.00. measured on programs containing small loops, is less • ρ : A transition relation. This is an assertion than a second. ρ(V; V 0), relating a state s 2 Σ to its successor s0 2 Σ by referring to both unprimed and primed versions of the state variables. The transition re- 2. RELATED WORK 0 0 lation ρ(V; V ) identifies state s as a successor of To the best of our knowledge, no other work can di- state s if hs; s0i j= ρ(V; V 0); where hs; s0i is the joint rectly validate software pipelining optimization. The interpretation which interprets x 2 V as s[x], and work of Necula [10] which aims towards validation of x0 as s0[x]. Thus, for example, the transition re- a rich class of optimizations does not try to validate lation may include \y0 = y + 1" to denote that this particular optimization. The method used there the value of the variable y in the successor state applies various heuristics to recover and identify the is greater by one than its value in the old (pre- optimizations performed and the associated refinement transition) state. mapping. It is based on a special-purpose verification engine included in the tool. Whereas, we are using the A computation of a transition system S is a max- method used by VOC that is described in [15]. However, imal finite or infinite sequence of states σ : s0;s1; :::; it is extended to handle a specific optimization typical starting with a state that satisfies the initial condition to EPIC processors. While VOC [14] handles machine and, every two consecutive states are related by a tran- independent optimizations which are done in an early sition relation, i.e. 9τ :< si; si+1 > ρτ for every i, stage of the compiler, our research concentrates on the 0 ¡ i + 1 <j σ j. code generation stage which, for EPIC processors such Let SS = hVS ; OS ; ΘS ; ρS i and ST = hVT ; OT ; ΘT ; ρT i as the IA64 involves aggressive optimizations. VOC uses be two transition systems, to which we refer as the step [2] as the verification engine, and thus the proof can source and target S's, respectively. We denote by X 2 OS not be done automatically. and x 2 OT the corresponding observable variables in Works that do handle the code generation part the two systems. We say that ST is a correct translation of a compiler are those based on the Verifix project as (refinement) of SS if for every finite (i.e., terminating) T T T described in [13] and [6], yet they can handle a limited PT -computation σ : s0 ; : : : ; sm, there exists a finite S S S T S type of optimizations and code selection. In particular PS -computation σ : s0 ; : : : ; sk , such that sm[x] = sk [X] they do not address software pipelining optimization. for every X 2 OS . The verification engine used in the Verifix project is the verification tool PVS, but usually the proofs are automatic. 4. BLOCK PROGRAMS Another approach, described in [8] requires a real ex- ecution of the code. This limitation may not be accept- Block programs are programs constructed out of blocks able in many embedded systems. of instructions. Where instructions are the legal ma- The work described in [5] does handle optimizations chine instructions of the underlying physical processor. which are close to loop pipelining in the sense that it An instruction changes the state of the processor by as- addresses a parallel DSP processor. It uses the checker signing new values to the processor memory and reg- approach, and requires a very strong relation between isters. We divide the group of possible instructions the compiler and the checker. to: branch instructions, which are either conditional instruction (branch < condition> < label>), or uncon- ditional one (branch<label>), and regular instructions. 3. TRANSITION SYSTEMS A block is a sequence of instructions with no branch, As common formal semantics for both source and tar- except, possibly, the last instruction of the block. The get systems, we introduce Transition Systems S, a vari- <label> in a branch instruction is the branch destina- ant of the transition systems of [9]. A Transition System tion, and its value is the index of a block. A branch S =< V; O; Θ; ρ > is given by the following compo- destination starts a block. nents: A block program P is constructed out of blocks. Let P = fB0;:::Bng be a program, then B0 is the entry • A finite set V of system variables, The variables in block. Each block B of a program may have one or V are typed, and a state of a S is a type-consistent two successors, denoted by succ(B) . If the last in- interpretation of the variables. One of the vari- struction of Bi is regular then succ(Bi) = fBi+1g. If ables is the control variable which represents the the last instruction is a unconditional branch with des- location of the control of the program. For a state tination Bj , then succ(Bi) = fBj g. If the last instruc- s and a variable x 2 V , we denote by s[x] the value tion is a conditional branch with destination Bj , then that s assigns to x. succ(Bi) = fBj ; Bi+1g. Each machine code program P, corresponds to a tran- • O ⊆ V a set observable variables. The observable sition system SP =< V; O; Θ; ρ > given by the following variables are the variables which are visible to the components: external world. • V = fv1; :::; vng [ fpcg is a finite set of system • Θ an initial condition characterizing the initial variables.