Equality-Based Translation Validator for LLVM

Transcription

1 Equality-Based Translation Validator for LLVM Michael Ste, Ross Tate, and Sorin Lerner University of California, San Diego Abstract. We udated our Peggy tool, reviously resented in [6], to erform translation validation for the LLVM comiler using a technique called Equality Saturation. We resent the tool, and illustrate its effectiveness at doing translation validation on SPEC 2006 benchmarks. 1 Introduction Comiler otimizations have long layed a crucial role in the software ecosystem, allowing rogrammers to exress their rograms at higher levels of abstraction without aying the erformance cost. At the same time, however, rogrammers also exect comiler otimizations to be correct, in that they reserve the behavior of the rograms they transform. Unfortunately, this seemingly simle requirement is hard to ensure in ractice. One aroach to imroving the reliability of comiler otimizations is a technique called Translation Validation [4]. After each run of the otimizer, a searate tool called a translation validator tries to show that the otimized rogram is equivalent to the corresonding original rogram. Therefore, a translation validator is just a tool that tries to show two rograms equivalent. In our own revious work [6], we develoed a technique for reasoning about rogram equivalence called Equality Saturation, and a tool called Peggy that imlements this technique. Although our aer focused mostly on erforming comiler otimizations using Peggy, we also showed how Equality Saturation can be used to erform translation validation, and that Peggy is an effective translation validator for Soot, a Java bytecode-to-bytecode otimizer. Insired by the recent results of Tristan, Govereau and Morrisett [7] on translation validation for LLVM [1], we have udated our Peggy tool so that it can be used to erform translation validation for LLVM, a more aggressive and more widely used comiler than Soot. This udated version of Peggy reuses our reviously develoed equality saturation engine described in [6]. However, we had to develo several new, LLVM-secific comonents for Peggy: an LLVM frontend for the intermediate reresentation used by our equality-saturation engine; new axioms for our engine to reason about LLVM loads, s and calls; and an udated constant folder that takes into account LLVM oerators. Finally, we resent new exerimental results showing the effectiveness of Peggy at doing translation validation for LLVM on SPEC 2006 C benchmarks.

2 2 Michael Ste, Ross Tate, and Sorin Lerner int f(,t) { * := t * := * (t & 4) return 0 int g(,t) { * := t (t & 4) return 0 (a) (b) f v (c) 0 g v f load g & t 4 Fig. 1. (a) Original code (b) Otimized code (c) Combined E-PEG. 2 Overview We first resent several examles demonstrating how Peggy erforms translation validation. These examles are distilled versions of real examles that we found while doing translation validation for LLVM on SPEC Examle 1. Consider the original code in Figure 1(a) and the otimized code in Figure 1(b). There are two otimizations that LLVM alied here. First, LLVM erformed coy roagation through the location *, thus relacing * with t. Second, LLVM removed the now-useless * := t. Our aroach to translation validation uses a reresentation that we develoed and resented reviously called Program Exression Grahs [6] (PEGs). A PEG is a ure functional reresentation of the rogram which has nice roerties for reasoning about equality. Figure 1(c) shows the PEGs for f and g. The labels f v and f oint to the value and hea returned by f resectively, and likewise for g for now, let us ignore the dashed lines. In general, a PEG is a (ossibly cyclic) exression grah. The children of a node are shown grahically below the node. Constants such as 4 and 0 have no children, and nodes with a square around them reresent arameters to the function and also have no children. PEGs encode the hea in a functional way using the standard oerators load and. In articular, given a hea and a ointer, load(, ) returns the value at address ; given a hea, a ointer, and a value v, (,, v) returns a new hea identical to, excet that the value at address is v. The PEG for f takes a hea as an inut arameter (in addition to and t), and roduces a new hea, labeled f, and a return value, labeled f v. Our aroach to translation validation builds the PEGs for both the original and the otimized rograms in the same PEG sace, meaning that nodes are reused when ossible. In articular note how t & 4 is shared. Once this combined PEG has been constructed, we aly equality saturation, a rocess by which equality axioms are reeatedly alied to infer equalities between PEG nodes. If through this rocess Peggy infers that node f is equal to node g and that node

3 Equality-Based Translation Validator for LLVM 3 char* f(,s,r) { x := strchr(s,*) *r := *+1 return x char* g(,s,r) { t := * x := strchr(s,t) *r := t+1 return x (a) (b) (c) f v g v ρ v true 1 only-reads strchr f r call ρ 5 + load arams s load g r Fig. 2. (a) Original code (b) Otimized code (c) Combined E-PEG. f v is equal to node g v, then Peggy has shown that the original and otimized functions are equivalent. In the diagrams we use dashed lines to reresent PEG node equality (in the imlementation, we equivalence classes of nodes using Tarjan s union-find data structure). Note that E-PEGs are similar to E-grahs from SMT solvers like Simlify [3] and Z3 [2], but secialized for reresenting rograms and with algorithms secialized to handle cyclic exressions which arise much more frequently in E-PEGs than in tyical SMT roblems. Peggy roves the equivalence of f and g in the following three stes: Peggy adds equality 1 using axiom: load((,, v), ) = v Peggy adds equality 2 by congruence closure: a = b f(a) = f(b) Peggy adds equality 3 by axiom: ((,, v 1 ),, v 2 ) = (,, v 2 ) By equality 3, Peggy has shown that f and g return the same hea, and are therefore equivalent since they are already known to return the same value 0. Examle 2. As a second examle, consider the original function f in Figure 2(a) and the otimized version g in Figure 2(b). is a ointer to an int, s is a ointer to a char, and r is a ointer to an int. The function strchr is art of the standard C library, and works as follows: given a string s (i.e., a ointer to a char), and an integer c reresenting a character 1, strchr(s,c) returns a ointer to the first occurrence of the character c in the string, or null otherwise. The otimization is correct because LLVM knows that strchr does not modify the hea, and the second load * is redundant. The combined PEGs are shown in Figure 2(c). The call to strchr is reresented using a call node, which has three children: the name of the function, the incoming hea, and the arameters (which are assed as a tule created by the arams node). A call node returns a air consisting of the return value and 1 It may seem odd that c is not declared a char, but this is indeed the interface.

4 4 Michael Ste, Ross Tate, and Sorin Lerner int f(x,y,z) { for (t:=0; t<z; t:=x*y+t) { return t (a) int g(x,y,z) { xy := x*y for (t:=0; t<z; t:=xy+t) { return t (b) (c) f v g v eval θ 0 + * x y ass z f g Fig. 3. (a) Original code (b) Otimized code (c) Combined E-PEG. the resulting hea. We use rojection oerators ρ v and ρ to extract the return value and the hea from the air returned by a call node. To give Peggy the knowledge that standard library functions like strchr do not modify the hea, we have annotated such standard library functions with an only-reads annotation. When Peggy sees a call to a function f oo annotated with only-reads, it adds the equality only-reads(f oo) = true in the PEG. Equality 1 in Figure 2(c) is added in this way. Peggy adds equality 2 using: only-reads(n) = true ρ (call(n,, )) =. This axiom encodes the fact that a read-only function call does not modify the hea. Equalities 3, 4, and 5 are added by congruence closure. In these 5 stes, Peggy has identified that the heas f and g are equal, and since the returned values f v and g v are trivially equal, Peggy has shown that the original and otimized functions are equivalent. Examle 3. As a third examle, consider the original code in Figure 3(a) and the otimized code in Figure 3(b). LLVM has ulled the loo-invariant code x*y outside of the loo. The combined PEG for the original function f and otimized function g is shown in Figure 3. As it turns out, f and g will roduce the exact same PEG, so let us focus on understanding the PEG itself. The θ node reresents the sequence of values that t takes throughout the loo. The left child of the θ node is the first element of the sequence (0 in this case) and the right child rovides any element in the sequence after the first one in terms of the revious element. The eval/ass air is used to extract the value of t after the loo. The node is a lifting of to sequences, and so it reresents the sequence of values that t z takes throughout the loo. ass takes a sequence of booleans and returns the index of the first boolean in the sequence that is true. Therefore ass in this case returns the index of the last iteration of the loo. eval takes a sequence of values and an integer index, and returns the element of the sequence at that index. Therefore, eval returns the value of t after the last iteration of the loo (a denotational semantics of PEGs can be found in [6]). As Figure 3 shows, the PEG for the otimized function g is the same as the original function f. Peggy has validated this examle just by converting to PEGs, without even running equality saturation. One of the key advantages of PEGs is

5 Equality-Based Translation Validator for LLVM 5 that they are agnostic to code-lacement details, and so Peggy can validate code lacement otimizations such as loo-invariant code motion, lazy code motion, and scheduling by just converting to PEGs and checking for syntactic equality. 3 Imlementation Axioms. Peggy uses a variety of axioms to infer equality information. Some of these axioms were reviously develoed and state roerties of built-in PEG oerators like θ, eval, ass, and φ (which are used for conditionals). We also imlemented LLVM secific axioms to reason about load and, some of which we have already seen. An additonal such axiom is imortant for moving unaliased loads/s across each other: q load((, q, v), ) = load(, ). Alias Analysis. The axiom above can only fire if q, requiring alias information. Our first attemt was to encode an alias analysis using axioms, and run it using the saturation engine. However, this added a significant run-time overhead, and so we instead took the aroach from [7], which is to re-comute alias information; we then used this information when alying axioms. Generating Proofs. As described in our follow-u work [5], after Peggy validates a transformation it can use the resulting E-PEG to generate a roof of equivalence of the two rograms. This roof has already heled us determine how often axioms are useful. In the future, we could also use this roof to imrove the run-time of our validator: after a function f has been validated, we could record which axioms were useful for f, and enable only those axioms for subsequent validations of f (reverting back to all axioms if the validation fails). 4 Results We used Peggy to erform translation validation for LLVM 2.8 on SPEC 2006 C benchmarks. We enabled the following otimizations: dead code elimination, global value numbering, artial redundancy elimination, sarse conditional constant roagation, loo-invariant code motion, loo deletion, loo unswitching, dead elimination, constant roagation, and basic block lacement. Figure 4 shows the results: #func and #instr are the number of functions and instructions; %success is the ercentage of functions whose comilation Peggy validated ( All considers all functions; OC, which stands for Only Changed, ignores functions for which LLVM s outut is identical to the inut); To PEG is the average time er function to convert from CFG to PEG; Avg Engine Time is the average time er function to run the equality saturation engine ( Success is over successful runs, and Failure over failed runs). Overall our results are comarable to [7]. However, because of imlementation differences (including the set of axioms), an in-deth and meaningful exerimental comarison is difficult. Nonetheless, concetually the main difference is that [7] uses axioms for destructive rewrites, whereas we use axioms

6 6 Michael Ste, Ross Tate, and Sorin Lerner Benchmark #func #instr %success To Avg Engine Time All OC PEG Success Failure 400.erlbench 1, , % 73.3% 0.531s 1.028s 11s 401.bzi , % 76.9% 0.253s 0.733s 19s 403.gcc 5, , % 74.9% 0.558s 0.700s 19s 429.mcf 24 2, % 87.0% 0.216s 0.500s 19s 433.milc , % 75.0% 0.246s 0.188s 9s 456.hmmer , % 84.6% 0.285s 0.900s 11s 458.sjeng , % 72.5% 1.099s 0.253s 7s 462.libquantum 115 5, % 64.3% 0.123s 0.167s 8s 464.h264ref , % 70.5% 0.587s 0.846s 12s 470.lbm 19 3, % 76.5% 0.335s 0.154s 3s 482.shinx , % 86.0% 0.208s 0.480s 12s Fig. 4. Results of running Peggy s translation validator on SPEC 2006 benchmarks. to add equality information to the E-PEG, thus exressing multile equivalent rograms at once. Our aroach has several benefits over [7]: (1) we simultaneously exlore an exonential number of aths through the sace of equivalent rograms, whereas [7] exlores a single linear ath hence we exlore more of the search sace; (2) we need not worry about axiom ordering, whereas [7] must ick a good ordering of rewrites for LLVM hence it is easier to adat our aroach to new comilers, and a user can easily add/remove axioms (without worrying about ordering) to balance recision/seed or to secialize for a given code base; (3) our aroach effectively reasons about loo-induction variables, which is more difficult using the techniques in [7]. However, the aroach in [7] is faster, because it exlores a single linear ath through the sace of rograms. Failures were caused by: (1) incomlete axioms for linear arithmetic; (2) insufficient alias information; (3) LLVM s use of re-comuted interrocedural information, even in intrarocedural otimizations. These limitations oint to several directions for future work, including incororating SMT solvers and better alias analyses, and investigating interrocedural translation validation. References 1. The LLVM comiler infrastructure. htt://llvm.org. 2. L. de Moura and N. Bjørner. Z3: An efficient SMT solver. In TACAS, D. Detlefs, G. Nelson, and J. B. Saxe. Simlify: a theorem rover for rogram checking. J. ACM, 52(3): , A. Pnueli, M. Siegel, and E. Singerman. Translation validation. In TACAS, R. Tate, M. Ste, and S. Lerner. Generating comiler otimizations from roofs. In POPL, R. Tate, M. Ste, Z. Tatlock, and S. Lerner. Equality saturation: a new aroach to otimization. In POPL, J.-B. Tristan, P. Govereau, and G. Morrisett. Evaluating value-grah translation validation for LLVM. In PLDI, 2011.