A Framework for Cooperating Decision Procedures

1. A Framework for Cooperating Decision Procedures Clark W. Barrett David L. Dill Aaron Stump Computer Systems Laboratory Stanford University

2. Outline • Motivation • The Framework • Correctness of the Framework • Using the Framework • Conclusions

3. The Need for Decision Procedures • Many interesting and practical problems can be expressed as problems in a decidable theory. • General purpose decision procedures can save time and effort when approaching new problems. • Decision procedures have been used in theorem proving, model checking, symbolic simulation, system specification, and other applications, many of which were unanticipated.

4. The Stanford Validity Checker (SVC) • This work is a result of ongoing attempts to improve the decision procedures of SVC. • Despite theoretical and architectural weaknesses, SVC has been surprisingly successful. • Our goals with SVC include the following: • Provably correct, • Adequately expressive, yet still decidable, • Flexible and easy to extend, • Maximum performance.

5. SVC Core: Cooperating Decision Procedures • Suppose are decidable theories, with disjoint signatures • Let and •  is a quantifier-free formula in the language of . • Is  satisfiable in the theory

6. Cooperating Decision Procedures • Two main approaches • Nelson and Oppen [‘79] • Shostak [‘84] • Original papers are confusing and incomplete. • [Tinelli & Harandi ‘96] • [Cyrluk et al. ‘96, Shankar & Ruess ‘00] • This work seeks to unify and further clarify these two approaches.

7. Outline • Motivation • The Framework • Correctness of the Framework • Using the Framework • Conclusions

8. Preliminaries • Expressions • DAG representation of terms and formulas. • Operator applied to 0 or more children. • Union-Find • Each expression (including Boolean constants true and false) belongs to an equivalence class with a unique representative. • Find(x) returns the equivalence class representative of x. • Union(x,y) merges the equivalence classes associated with x and y and makes y the new representative.

9. Framework Interface • AddFormula() ( a literal in  ) • C := C  {}; (Initially, C = Ø) • Satisfiable() • Returns TRUE iff Find(true)  Find(false). • Satisfiability of an arbitrary formula in  is determined by converting  to DNF and then testing each conjunct for satisfiability.

10. Merge Assert AddFormula Setup Simplify Rewrite The Framework    ’ Propagate t’ t a=b a,b t a=b t t’ Theory-specific code

11. AddFormula and Assert • Assert() processes the formula  by first simplifying it and then calling Merge. • AddFormula is a wrapper around Assert which allows each theory to assert new facts. Assert() ’ := Simplify(); IF ’ not an equation THEN ’ := (’ = true); Merge(’); AddFormula() Assert( ); REPEAT FOREACH theory i DO Propagate(i); UNTIL no change;

12. Merge Assert AddFormula Setup Simplify Rewrite The Framework    ’ Propagate t’ t a=b a,b t a=b t t’ Theory-specific code

13. Simplify and Rewrite • Simplify returns an expression which is equivalent in the current context. • Recursively replaces each sub-expression with its equivalence class representative. • Applies theory-specific rewrites. Simplify() IF Find() THEN RETURN Find(); ’ := Simplify each child of ; ’ := Rewrite(’); RETURN ’; Rewrite(t) t’ := TheoryRewrite(t); IF t  t’ THEN t’ := Rewrite(t’); RETURN t’;

14. Merge Assert AddFormula Setup Simplify Rewrite The Framework    ’ Propagate t’ t a=b a,b t a=b t t’ Theory-specific code

15. Setup and Merge • Merge records that two expressions a and b are equal by merging their equivalence classes. • Calls Setup on each expression. • Notifies theories that care about a. Merge(a=b) Setup(a);Setup(b); Union(a,b); FOREACH <f,d>a.notify Call f(a=b,d); Setup(t) IF Find(t) THEN RETURN; FOREACH child c Setup(c); TheorySetup(c); Find(c) := c;

16. true a = b    Merge Assert AddFormula Setup Simplify Rewrite ’ Propagate t’ t a=b a,b t a=b t t’ Theory-specific code A Simple Example Find(a) = b a = b a = b a = b a = b true a = b b = b true b = b b = b  true

17. Outline • Motivation • The Framework • Correctness of the Framework • Using the Framework • Conclusions

18. Approach to Correctness • Develop a set of preconditions and requirements that must hold for the framework to be correct. • Prove that, as long as the code associated with individual theories adheres to these general requirements, the framework is correct. • Prove the main theorems once, then prove a small set of theorems each time a theory is added.

19. Example: Completeness • Theorem [Tinelli et al. ‘96]: LetT1and T2be two disjoint theories and let1be a formula in the language ofT1 and 2 a formula in the language of T2. Let V be the set of their shared variables and let (V) be an arrangement of V. If 1(V) is satisfiable in T1 and 2(V) is satisfiable in T2, then 1  2is satisfiable inT1 T2.

20. Example: Completeness • Every formula recorded by Merge is associated with an individual theory. • Each theory Tidetermines whether the conjunction of its formulas together with the arrangement of shared variables induced by the expression equivalence classes is satisfiable in Ti. • By application of the previous theorem, we can then determine whether the conjunction of all formulas recorded by Merge is satisfiable.

21. Outline • Motivation • The Framework • Correctness of the Framework • Using the Framework • Conclusions

22. Merge Assert AddFormula Setup Simplify Rewrite The Framework    ’ Propagate t’ t a=b a,b t a=b t t’ Theory-specific code

23. Nelson-Oppen Style Combinations • Input formulas are transformed into equivalent formulas, each of which is in a single theory. • Suppose f and g are symbols from two different theories. • Each theory must determine whether any equalities between (shared) variables are entailed by its formulas and propagate these equalities.

24. Our Approach to Nelson-Oppen • The flexible nature of the framework allows us to directly implement and prove correctness of a more efficient algorithm: • Don’t transform the formulas or introduce new variables. It is sufficient to partition the formulas and mark which terms are “used” by more than one theory. • Only propagate equalities between terms used by more than one theory, and only to theories which use the left side of the equality.

25. Nelson-Oppen Example • Combines three theories: • Uninterpreted functions • Arithmetic with inequalities • Arrays

26. Merge Assert AddFormula Setup Simplify Rewrite Nelson-Oppen Example   ’ Propagate t’ t a=b a,b t a=b t t’ Uninterpreted Arithmetic Arrays

27. Shostak Style Combinations • More efficient than Nelson-Oppen, but not as widely applicable. • Only applies to theories which are canonizable and algebraically solvable. • Input formulas are solved for a single variable. • No need to propagate equalities.

28. Our Approach to Shostak • Use theory-specific Rewrite code to solve and canonize formulas. • Both Shostak and Nelson-Oppen style theories can be integrated in the same framework. • Proof of correctness is easier than in other treatments of Shostak because we can treat uninterpreted functions as belonging to a separate Nelson-Oppen style theory.

29. Outline • Motivation • The Framework • Correctness of the Framework • Using the Framework • Conclusions

30. Conclusions • What Have We Learned? • There is a demand for efficient cooperating decision procedures. • Getting it right is hard. • A solid theoretical foundation is necessary. • Future Work • The next version of SVC is under development. • New theories. • Relax restrictions on what kinds of theories can be integrated.

31. Stay tuned • Visit the SVC home page at http://verify.stanford.edu/SVC