Added logic to simplifier that creates equality out of > and < #229
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds the ability to concertize a variable's value by
using inequalities to find the range of values a variable can be.
Should the range be reduced to a single value, then the variable
can be concertized. For example if the state contains the constraints
(x>6) and (x<=7) then we know that (x==7). This equality can then be
used to simplify the incoming query.expr to a smaller and more
manageable form. Sometimes the query.expr can be simplified to a
concrete value, eliminating the need for a Solver call at all.
I ran my experiments with all of my other, pending, pull requests turned on. I did this in order to show the potential increases in speed of this technique (Without the other improvements, the effects of this pull request get washed out.) I can, however, rerun the experiments given the current state of Klee if you would like.
Command line options
--search=dfs --max-forks-terminate=32000
Of the six programs that finished, there was an average reduction in Solver calls of 26%. This ranged from "addr2line" which only saw a 17% drop (358 to 304) to "readelf" which saw a 32% drop (1086 to 866). In terms of performance, there was a 17% reduction in overall time required to complete the exploration. In the worst case "size" saw only a 10% drop (707 seconds to 642 seconds). In the best case "readelf" saw a 42% reduction in the overall time required to complete the exploration (189 seconds to 111 seconds).
For each of these six programs there was an identical number of instructions covered for the two different versions I tested.
--search=default
I did not run a regular search since, as we discussed in previous pull requests, the results are not directly comparable. I can, however, run these experiments and aggregate them if you'd like.