From Verication to Optimizations Rigel Gjomemoa, Kedar S. Namjoshib, Phu H. Phungc;a, Venkat Venkatakrishnana, and Lenore D. Zucka a University of Illinois at Chicago, {rgjomemo,phu,venkat,lenore}@cs.uic.edu b Bell Laboratories, Alcatel-Lucent, [email protected] c University of Gothenburg, Sweden Abstract. Compilers perform a static analysis of a program prior to optimization. The precision of this analysis is limited, however, by strict time budgets for compilation. We explore an alternative, new approach, which links external sound static analysis tools into compilers. One of the key problems to be solved is that of propagating the source-level information gathered by a static analyzer deeper into the optimization pipeline. We propose a method to achieve this, and demonstrate its fea- sibility through an implementation using the LLVM compiler infrastruc- ture. We show how assertions obtained from the Frama-C source code analysis platform are propagated through LLVM and are then used to substantially improve the eectiveness of several optimizations. 1 Introduction An optimizing compiler is commonly structured as a sequence of passes. The input of each pass is a source code that is rst analyzed and, using the analysis information, transformed to a target code, which then becomes the source of the next pass in the sequence. Each pass uses static analysis to guide optimization, but the precision of this analysis is limited due to strict time budgets for compil- ing (e.g., the GCC wiki has as rule 1: Do not add algorithms with quadratic or worse behavior, ever.") As a result, end users of compilers such as LLVM do not benet from advances in algorithms for program analysis and verication. These advanced methods are, however, implemented in static analysis tools, which are now widely used to detect programming errors during software development. Examples such tools for C programs include BLAST [10], Frama-C [5], and F- Soft [11], all of which employ SMT solvers to produce high-quality and precise (inductive) invariants. Static analysis tools are less time-constrained and are thus able to carry out much deeper analysis of program behavior. In this work we explore how the information gathered by such tools can be used to augment the internal analysis of a compiler, and whether this oers any practical benet. While the compile-time cost of employing additional tools may be high, it is often the case that runtime improvements in optimization outweigh this additional cost, for example, for large frequently used code such as kernels and name servers. One approach is to implement these as optional features inside the compiler. Yet another option, employed here, is that of importing the analysis results computed by external static analysis and software verication tools. There is much to be gained from this modular approach, which decouples analysis from transformation. However, there are two key challenges to be overcome: Linking the output of an analysis tool to the C program representation in the compiler front-end, and propagating the assertions through the program transformations performed at the back-end. Let us consider the problem of propagating information through a series of optimization passes. The static analysis tool produces information about a source program, say S. However, the various passes of a compiler transform S successively into programs S = S0;S1;S2;:::;Sf = T , where T denotes the nal th target code. To use information gathered for S0 at the k compilation stage (k > 0), one must have a way of transforming this information into a form that is meaningful for program Sk−1. A simple example can illustrate this problem. Suppose that the program S has variables x and y, and the static analysis tool concludes that (x < y) is invariant. Now suppose that the rst stage of compilation renames x and y to temporary" variables t1 and t2 respectively. The assertion (x < y) is meaning- less for the second compilation stage (from S1 to S2); to be useful, it must be transformed to (t1 < t2). How can assertions be transformed? It is desirable to avoid manually tailoring the propagation of assertions to each transformation, a laborious and possibly error-prone task. Our approach oers a uniform method for assertion propaga- tion, which is based on the notion of renement witnesses" [14]. Note that when the renement relation induced by a transformation is available, it can be used to transform any invariant on the source program to an invariant on the target program 1. We obtain the renement relation by instrumenting the optimization to produce a renement relation as it transforms a program. (The validity of the generated relation can be checked independently, using SMT solvers. A valid relation is a witness" to the correctness of the optimization, hence the name.) Many standard optimizations only introduce, remove, or rename variables. Thus, witness relations are often conjunctions of equalities between a pair of cor- responding source/target variables at a program point (or of the form vt = E(Vs) where vt is a target variable, Vs are a source variables, and E is a simple arithmetic expression.) For example, the witness for a dead-variables elimina- tion transformation states that the values of live variables are preserved. In the common case that the invariant depends on a single variable, its propagation can be carried out by simply keeping track of the action that is applied to the variable, without requiring logical manipulations. In the implementation described in this paper, we handle this common case. The invariants are obtained from the value-range analysis of the Frama-C source code analysis platform [5, 3]. Among other information, Frama-C (via its Value Analysis plug-in) produces invariants which express constant limits on the range 1 Precisely, if ' is invariant for program S, and T renes S through relation W , then hW i' is invariant for T . 2 of a program variable (e.g., 10 ≤ x ≤ 20). Such invariants are propagated through LLVM optimizations using a mechanism we describe in Sec. 3. The propagated invariants are used to augment LLVM's own analysis information for optimiza- tions such as instruction combination and buer overrun checking2. Sec. 5 de- scribes some experimental results showing gains vary depending on the relative accuracy of LLVM vs. Frama-C for each benchmark. The prototype of our implementation is available at http://www.cs.uic.edu/ ~phu/projects/aruna/index.html. 2 Approach By Example We use LLVM [12] as our target compiler infrastructure due to its widespread use in academic and industrial settings, as well as its ability to handle a wide variety of source languages. Among several tools (e.g., [5, 2, 18, 9, 1, 13]) that can be used to obtain external assertions to feed into LLVM, we focus our discussion on Frama-C. In particular, we focus on the use of Frama-C to perform value analysis, an abstract-interpretation-based analysis, to obtain various domains of integers (sets of values, intervals, periodic intervals), oating points, and ad- dresses for pointers. The value range analysis results obtained from Frama-C are more powerful than those available in most compilers, and, as we demonstrate, in LLVM. Consider the code in Fig. 1(a). Even when compiled using the most aggressive optimization scheduler (-O3 option of Clang), LLVM's optimizer does not detect that the else branch in location L6 is dead (and leaves the branch L6-L7 intact.) In Fig. 1(b) we show the ACSL ([6], see also http://frama-c.com/acsl.html) assertions produced by the Frama-C's Value Analysis as comments. We note that here examples are given at the C-level for readability, rather then the SSA LLVM bitcode. The assumption of SSA form allows to consider each assertion in a basic block (single-entry single-exit straight line code) to be implicitly the conjunction of assertions preceding it. We thus omit describing how the assertions produced by Frama-C (comments in Fig. 1(b)) are propagated from the Clang input. The rst pass that LLVM performs that is relevant to us is to replace weak inequalities by strict inequal- ities, possibly at the cost of introducing new variables, and replacing, signed comparisons between integers with unsigned ones (subscripted by u) whenever the integers are known to be non-negative. Consider the uncommented lines in Fig. 1(c). There, a new line (L0) is added in which a temporary variable tmp1 is assigned the value i − 1, which, when i ≥ 1, is non-negative, and hence line L1 does not test it is greater than 0. This allows LLVM to replace the conjunction of the test in L1 by a single unsigned test for tmp1 <u 10. Following the quest to replace tests of weak inequality to tests for strict inequalities, LLVM replaces that tests in L2 and L3 by their strict equivalents. Finally, the j + i expression that appears in line L4 (Fig. 1(b)) is 2 The latter inserts checks; the invariants help identify some which as unnecessary. 3 replaced by two lines, one (L3.1) that assigns a new tmp2 the value j + i, and the other (L4) tests whether tmp2 ≥ k (this inequality is left in its weak form, since neither of the operands is a constant.) Since the original program does not have the new temporaries, there is no value-range analysis for them. However, we can propagate the assertion i ≥ 1 ^ i ≤ 10 to the assertion tmp1= i − 1 ^ tmp1 ≥ 0 ^ tmp1 ≤ 9, as appears in L1' of Fig. 1(c). Similarly, using the assertion for i and the assertion j ≥ 5 (from L2'), we can propagate the assertion tmp2 = i + j ^ tmp2 ≥ 6, which is shown in line L3.1' of Fig.