miniBDD: added a non-recursive variant of APPLY#1144
Conversation
|
A performance comparison would be interesting. |
tautschnig
left a comment
There was a problem hiding this comment.
See detailed comments plus all the linter's complaints.
src/solvers/miniBDD/miniBDD.cpp
Outdated
There was a problem hiding this comment.
Contesting for the least descriptive type name of the year? :-) In absence of any comment, this isn't exactly helping readability.
There was a problem hiding this comment.
technically, t would be ok
src/solvers/miniBDD/miniBDD.cpp
Outdated
There was a problem hiding this comment.
There is no case other than INIT or FINISH, the default is unnecessary.
src/solvers/miniBDD/miniBDD.cpp
Outdated
There was a problem hiding this comment.
Why is key not being initialised? (It is done via a separate assignment later on for some reason.)
src/solvers/miniBDD/miniBDD.cpp
Outdated
src/solvers/miniBDD/miniBDD.cpp
Outdated
There was a problem hiding this comment.
I'd prefer
enum class phaset { INIT, FINISH};
phaset phase;
src/solvers/miniBDD/miniBDD.cpp
Outdated
src/solvers/miniBDD/miniBDD.cpp
Outdated
There was a problem hiding this comment.
INVARIANT instead of assert
There was a problem hiding this comment.
This is un-obvious: there is some intent to maintain MiniBDD as a library that can be separately distributed.
There was a problem hiding this comment.
In that case please add linter overrides (and possibly the above explanation).
|
@kroening I did some tests with EBMC on 4 smv models from
this is average run-time over 10 runs, with the patch for |
|
@mgudemann oh, wow, this is bigger than I thought it would be. |
db2da98 to
8a8f5f2
Compare
|
@kroening I'll see whether I find others that use a non-trivial amount of time and also do not require excessive resources when using BDDs. The above are all converted from AIG, that may skew the results a bit. I'll see whether I find other .smv or Verilog files. |
8a8f5f2 to
bda4ec5
Compare
|
Ready to go? |
|
I did a small benchmark on the
which shows a very slight advantage for the recursive variant with the exception of the first model. In conclusion I think the recursive version can be significantly worse (maybe if the recursion depth is very high?) and in the best case is slighly better (as it is shorter / less complex?) Overall, this is ready for merge. |
| { | ||
| t.var=x.var(); | ||
| t.phase=stack_elementt::phaset::FINISH; | ||
| assert(x.low().var()>t.var); |
There was a problem hiding this comment.
Linter overrides, please.
src/solvers/miniBDD/miniBDD.cpp
Outdated
| case stack_elementt::phaset::INIT: | ||
| { | ||
| // dynamic programming | ||
| t.key=std::pair<unsigned, unsigned>(x.node_number(), y.node_number()); |
There was a problem hiding this comment.
I think I've asked this before: why is this not part of the constructor?
bda4ec5 to
a71ca41
Compare
As said before I'm unhappy about the absence of tests, but I don't want to stand in the way of others approving of this.
|
|
||
| void mini_bdd_nodet::remove_reference() | ||
| { | ||
| // NOLINTNEXTLINE(build/deprecated) |
There was a problem hiding this comment.
Use PRECONDITION(), INVARIANT(), etc from https://github.com/diffblue/cbmc/blob/master/src/util/invariant.h rather than silencing the linter.
This adds a non-recursive variant of APPLY, for systems that have limited stacks.
The commit retains the recursive variant, which is much easier to read.