Loop-Invariant Synthesis using Techniques from Constraint Programming Antoine Miné Jason Breck Thomas Reps Hi, everyone. My name is Jason Breck, I’m a graduate student at the University of Wisconsin-Madison, this is joint work with my advisor, Tom Reps, and part of the larger Pliny project. I’m going to present some work on a loop invariant synthesis technique that borrows some ideas from the world of constraint programming. We are working to extend of a loop invariant synthesis algorithm called CPSolver, which was created by a collaborator of ours, Antoine Mine of ENS. In my talk today, I’ll first introduce the algorithm, then I’ll talk about how we have extended the algorithm and then what we plan to do next. Dagstuhl, November 2015

The Pliny Project Corpus Question for future work: How can we make the best use of loop invariants to support code search, synthesis, and repair? How best to: measure similarity between invariants relate buggy and fixed code program analysis database code search synthesis repair Dagstuhl, November 2015

The CPSolver Algorithm 𝑥 1 ∈ 2,4 𝑥 2 ∈[2,4] x2 4 Program states are in ℝd d=2 case may be visualized on the plane Invariants are geometric shapes. They may be approximated by sets of rectangles CPSolver iteratively refines a set of rectangles to find an invariant 2 -4 -2 2 4 x1 The CPSolver algorithm analyzes single-loop programs with real-valued variables, so in any loop that we analyze, you can think of a program state as being a vector of real numbers. In the case where we have two program variables, we can draw the space of program states on the plane for easy visualization, so, the horizontal axis is one program variable (say, x_1) and the vertical axis is another (say, x_2). Then, a loop invariant is some geometric shape, and we can approximate... What we mean by rectangle or box here is a conjunction of interval constraints... The CPSolver algorithm searches for an invariant by iteratively refining a set of boxes until either the set of boxes becomes an invariant, or else we reach a failure condition. This abstract domain of sets of boxes, and the techniques used to refine it, are ideas taken from constraint programming. -2 𝑥 1 ∈ 0,4 𝑥 2 ∈[−2,0] -4 Dagstuhl, November 2015

45° rotation with a slight inward scaling Now I’d like to show you an example of what this iterative process looks like. We’ll take the example of analyzing a loop whose body performs a 45 degree rotation of the point (x,y) with a slight inward scaling. No single box will be inductive, of course, because when you rotate a box 45 degrees, its corners map outside of the original box. Here’s what happens when you an example like this to CPSolver. The result is a shape that actually does map inside itself after a 45 degree rotation. 45° rotation with a slight inward scaling

Now I’d like to show you an example of what this iterative process looks like. We’ll take the example of analyzing a loop whose body performs a 45 degree rotation of the point (x,y) with a slight inward scaling. No single box will be inductive, of course, because when you rotate a box 45 degrees, its corners map outside of the original box. Here’s what happens when you an example like this to CPSolver. The result is a shape that actually does map inside itself after a 45 degree rotation.

The CPSolver Algorithm x2 4 2 -4 -2 2 4 x1 How do we refine our set of boxes? Well, basically, we split and delete boxes according to various rules. Here’s an example of the reasoning. Suppose that we determine that, when the program state is within this lower-right box here, one iteration of the loop that we’re analyzing will take the program state to the brown box shown here. That tells us that our current set of boxes is not an inductive loop invariant because it goes outside of our current set of boxes; we need to refine our set. So, what we will do is split this box, like so. Suppose now that this new lower-right box now maps, with one iteration of the loop, entirely outside our set of boxes; because it maps entirely outside, we’ll delete it. On the other hand, this box here maps entirely inside our set of boxes, so we will keep this box. If all of the boxes map entirely back into our set of boxes, then our set of boxes is an inductive loop invariant, and we’re done. -2 -4 Dagstuhl, November 2015

The CPSolver Algorithm x2 4 2 -4 -2 2 4 x1 How do we refine our set of boxes? Well, basically, we split and delete boxes according to various rules. Here’s an example of the reasoning. Suppose that we determine that, when the program state is within this lower-right box here, one iteration of the loop that we’re analyzing will take the program state to the brown box shown here. That tells us that our current set of boxes is not an inductive loop invariant because it goes outside of our current set of boxes; we need to refine our set. So, what we will do is split this box, like so. Suppose now that this new lower-right box now maps, with one iteration of the loop, entirely outside our set of boxes; because it maps entirely outside, we’ll delete it. On the other hand, this box here maps entirely inside our set of boxes, so we will keep this box. If all of the boxes map entirely back into our set of boxes, then our set of boxes is an inductive loop invariant, and we’re done. -2 -4 Dagstuhl, November 2015

The CPSolver Algorithm x2 4 2 -4 -2 2 4 x1 How do we refine our set of boxes? Well, basically, we split and delete boxes according to various rules. Here’s an example of the reasoning. Suppose that we determine that, when the program state is within this lower-right box here, one iteration of the loop that we’re analyzing will take the program state to the brown box shown here. That tells us that our current set of boxes is not an inductive loop invariant because it goes outside of our current set of boxes; we need to refine our set. So, what we will do is split this box, like so. Suppose now that this new lower-right box now maps, with one iteration of the loop, entirely outside our set of boxes; because it maps entirely outside, we’ll delete it. On the other hand, this box here maps entirely inside our set of boxes, so we will keep this box. If all of the boxes map entirely back into our set of boxes, then our set of boxes is an inductive loop invariant, and we’re done. -2 -4 Dagstuhl, November 2015

The Octagon Abstract Domain Box 𝑥 𝑖 ∈[ 𝑎 𝑖 , 𝑏 𝑖 ] Octagon 𝑥 𝑖 + 𝑥 𝑗 ∈[ 𝑎 𝑖,𝑗 , 𝑏 𝑖,𝑗 ] 𝑥 𝑖 − 𝑥 𝑗 ∈[ 𝑐 𝑖,𝑗 , 𝑑 𝑖,𝑗 ] Dagstuhl, November 2015

Relative Completeness An algorithm is relatively complete if provides this guarantee: If an inductive invariant exists in the abstract domain, and its inductiveness can be proven using the abstract domain, then the algorithm will find an inductive invariant. (related to “robustness” in [Madhusudan and Garg ‘14]) We created a relatively-complete version of CPSolver Dagstuhl, November 2015

Experiments Experimental design Results 11 simple, single-loop programs from the literature All variables are reals Box and octagon abstract domain Results Box domain: we found an invariant in all cases 3.84 sec average, 0.33 sec median Octagon domain: we found an invariant in all but 2 cases 29.8 sec average, 1.62 sec median Invariants are simpler (about half as many octagons as boxes) Dagstuhl, November 2015

Summary Concept Completed work Future work Thanks for your attention! Synthesize numerical loop invariants Use ideas from constraint programming (box abstract domain) Completed work Relatively-complete variant of original algorithm Use octagon abstract domain Future work Other abstract domains Applications in synthesis/repair or searching a Big Code corpus Thanks for your attention! Any questions? jbreck@cs.wisc.edu Dagstuhl, November 2015