1. 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

2. 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

3. 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

4. 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

5. 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.

6. The CPSolver Algorithmx2 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

7. The CPSolver Algorithmx2 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

8. The CPSolver Algorithmx2 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

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

10. 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

11. 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

12. 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?
Dagstuhl, November 2015