summaryrefslogtreecommitdiff
path: root/src/theory/theory_preprocessor.cpp
diff options
context:
space:
mode:
authorAndrew Reynolds <andrew.j.reynolds@gmail.com>2020-12-22 08:24:24 -0600
committerGitHub <noreply@github.com>2020-12-22 08:24:24 -0600
commita129c57c758b7161be23ebb12d41c05c72154ece (patch)
tree6b4a8c91dec9af3e9cd546e68320acf845d942c1 /src/theory/theory_preprocessor.cpp
parent85da37188e1b206fb3dccf202633cf4c1d22da7c (diff)
Make theory preprocess rewrite equalities a preprocessing pass (#5711)
Some theories rewrite equalities during ppRewrite. An example is arithmetic with the option arith-rewrite-eq, which rewrites (= x y) to (and (>= x y) (<= x y)) during theory preprocessing. This PR makes it so that ppRewrite is only called on equalities in preprocessing, during a new preprocessing pass "TheoryRewriteEq". On the other hand, ppRewrite is never called on new equalities generated in lemmas from TheoryEngine. In detail, the motivation for this change: (1) Rewriting equalities during ppRewrite is dangerous since it may break invariants wrt theory combination. In particular, equalities in splitting lemmas originating from theory combination must not be theory-preprocessed, or else we may be non-terminating or solution unsound. This can happen if a theory requests a split on (= x y) but is not notified of this atom when another theory rewrites (= x y) during ppRewrite. (2) After this PR, we can simplify our policy for all lemmas generated, in particular, we can say that all lemmas must be theory preprocessed before their literals are asserted to TheoryEngine. This is now possible as the invariant cannot be broken (theoryRewriteEq is relegated to the preprocessor, which is only applied once). This will make LemmaProperty::PREPROCESS obsolete, which in turn will simplify several lemma caches for nonlinear and quantifiers. It will also significantly simplify proof production for the theory preprocessor (which maintains two stacks of utilities for preprocessed vs non-preprocessed lemmas). (3) Simplifications to the above policy will make it significantly easier to implement theory-preprocessing apply when literals are asserted. It is currently not possible to implement this in a coherent way without tracking which literals were a part of lemmas marked as "do not theory-preprocess".
Diffstat (limited to 'src/theory/theory_preprocessor.cpp')
-rw-r--r--src/theory/theory_preprocessor.cpp17
1 files changed, 17 insertions, 0 deletions
diff --git a/src/theory/theory_preprocessor.cpp b/src/theory/theory_preprocessor.cpp
index 7c917dff5..c56554b53 100644
--- a/src/theory/theory_preprocessor.cpp
+++ b/src/theory/theory_preprocessor.cpp
@@ -450,6 +450,23 @@ Node TheoryPreprocessor::preprocessWithProof(Node term)
// be steps from the same term to multiple rewritten forms, which would be
// the case if we registered a preprocessing step for a non-rewritten term.
Assert(term == Rewriter::rewrite(term));
+ // We never call ppRewrite on equalities here, since equalities have a
+ // special status. In particular, notice that theory preprocessing can be
+ // called on all formulas asserted to theory engine, including those generated
+ // as new literals appearing in lemmas. Calling ppRewrite on equalities is
+ // incompatible with theory combination where a split on equality requested
+ // by a theory could be preprocessed to something else, thus making theory
+ // combination either non-terminating or result in solution soundness.
+ // Notice that an alternative solution is to ensure that certain lemmas
+ // (e.g. splits from theory combination) can never have theory preprocessing
+ // applied to them. However, it is more uniform to say that theory
+ // preprocessing is applied to all formulas. This makes it so that e.g.
+ // theory solvers do not need to specify whether they want their lemmas to
+ // be theory-preprocessed or not.
+ if (term.getKind() == kind::EQUAL)
+ {
+ return term;
+ }
// call ppRewrite for the given theory
TrustNode trn = d_engine.theoryOf(term)->ppRewrite(term);
if (trn.isNull())
generated by cgit on debian on lair
contact matthew@masot.net with questions or feedback