Skip to content

Add CaDiCaL support to CMake #4758

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 23, 2021
Merged

Conversation

tautschnig
Copy link
Collaborator

Add CMake configuration to build using CaDiCaL, which was already
supported with Makefiles. Also bump the version of CaDiCaL to sr19 and
fix the use of the cnf_solvert interface.

  • Each commit message has a non-empty body, explaining why the change was made.
  • n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
  • Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
  • n/a My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

@tautschnig
Copy link
Collaborator Author

FWIW: running the regression suite with CaDiCaL appears to be quite a bit slower, but an evaluation on more realistic benchmarks is yet to be done.

Copy link
Contributor

@smowton smowton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Build script stuff looks fine to me, no opinion on the solvers stuff that I'm not that familiar with

download_project(PROJ cadical
URL https://github.com/arminbiere/cadical/archive/sr19.tar.gz
PATCH_COMMAND true
COMMAND CXX=${CXX_COMPILER} CXXFLAGS=-O3 ./configure --debug
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double-check: is the --debug asking configure for verbose output, or setting -g for the build, or could it even be overriding the -O3 given in CXXFLAGS to get -g -O0?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did double-check when building locally: it just adds -g, the -O3 from CXXFLAGS is passed on as desired.

@codecov-io
Copy link

codecov-io commented Jun 6, 2019

Codecov Report

Merging #4758 (528164d) into develop (60feede) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #4758   +/-   ##
========================================
  Coverage    69.66%   69.67%           
========================================
  Files         1248     1248           
  Lines       100873   100874    +1     
========================================
+ Hits         70278    70279    +1     
  Misses       30595    30595           
Flag Coverage Δ
cproversmt2 43.38% <0.00%> (-0.01%) ⬇️
regression 66.64% <100.00%> (+<0.01%) ⬆️
unit 32.19% <50.00%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/solvers/refinement/refine_arithmetic.cpp 60.37% <ø> (-0.19%) ⬇️
src/solvers/refinement/bv_refinement_loop.cpp 94.23% <100.00%> (+0.23%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 60feede...528164d. Read the comment docs.

Copy link
Contributor

@allredj allredj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✔️
Passed Diffblue compatibility checks (cbmc commit: 7931e35).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/114606145

Copy link
Contributor

@thk123 thk123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any strong opinions on this, but it should probably build cadical on CI and run the tests?

@@ -79,6 +79,21 @@ propt::resultt satcheck_cadicalt::do_prop_solve()
}
else
{
// if assumptions contains false, we need this to be UNSAT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ I don't understand this change or why the assume falses need special casing, but it should probably go in its own commit explaining in more detail why this is required

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preferably with a test that only passes with this

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just for the record: this is done in keeping with other solvers, and thus about the way in which we use the solver interface. I agree that a test would be useful.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, the reason why 'assume false' needs special casing is that SAT solvers don't have a 'false' literal.

Copy link
Collaborator

@martin-cs martin-cs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems good to me.

Copy link
Member

@peterschrammel peterschrammel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest to merge also #5305 so that we can use the other solvers too without having to implement hardness_collectort everywhere.

Copy link
Contributor

@hannes-steffenhagen-diffblue hannes-steffenhagen-diffblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tautschnig I'm noticing that the second commit has quite a few related changes at once. Is there any chance these could be split up into indivial commits that still make sense on their own? No real issue with the changes themselves.


set_target_properties(
cadical
PROPERTIES IMPORTED_LOCATION ${cadical_SOURCE_DIR}/build/libcadical.a

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will only work on Linux, is that OK? If cadical also works on Windows/OSX it'd be nice if just used something like find_library here to get a more portable library path.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cadical's makefile hard-codes this, so I don't think it'll work out of the box on other platforms.

}
}

for(const auto &a : assumptions)
solver->assume(a.dimacs());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to do this now? This wasn't here previously?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support for assumptions simply was missing before.

@tautschnig
Copy link
Collaborator Author

@tautschnig I'm noticing that the second commit has quite a few related changes at once. Is there any chance these could be split up into indivial commits that still make sense on their own? No real issue with the changes themselves.

I'm not entirely convinced this adds value: the previous implementation was pretty broken, and not really usable. All these changes are necessary to make things work.

A SAT instance that is satisfiable need not remain so when adding
clauses. Solvers strictly asserting this (such as Cadical) would refuse
getting the model of a satisfiable instance after having added further
clauses since the last solve() call.

Thus, request the values of all approximations first, and only then add
further constraints. Doing so makes cbmc-library/Float-div1-refine pass
again, even when using Cadical.
Add CMake configuration to build using CaDiCaL, which was already
supported with Makefiles. Also bump the version of CaDiCaL to rel-1.3.0
and fix the use of the cnf_solvert interface.

Run the ubuntu-18_04-package GitHub PR action with -Dsat_impl=cadical to
avoid future regressions.

Fixes: diffblue#5348
@tautschnig tautschnig merged commit c0b29cb into diffblue:develop Jan 23, 2021
@tautschnig tautschnig deleted the cadical branch January 23, 2021 01:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants