Skip to content
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

Optionally skip re-verification of well-definedness #700

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

marcoeilers
Copy link
Contributor

Silicon verifies that predicate bodies, function preconditions, and method pre- and postconditions are self-framing and well-defined. As a result, it is not necessary to re-verify well-definedness when using them (but Silicon always does so anyway).

This PR adds a flag in the state that expresses whether well-definedness of the currently consumed or produced assertion needs to be checked. By default, this flag does nothing, but setting a command line option will lead to Silicon actually skipping the checks in those cases.

Additionally, it introduced another flag that expresses whether any conditions (well-definedness or correctness) should currently be checked or assumed. This is for later usage to enable us to skip verification of parts of methods if they are already known to be correct.

@Aurel300
Copy link
Member

Aurel300 commented Apr 3, 2023

Do we want this to become the default? I am guessing this improves performance.

@marcoeilers
Copy link
Contributor Author

I hoped it would, but it actually leads to worse performance on SCION code. So for now I basically just wanted to have this option available to experiment with.

@superaxander
Copy link
Contributor

I would be interested in using this flag. I tried it out and for my file it makes the difference between it (nondeterministically) failing to verify and verifying. I think this is because I have a lot of heap chunks in the state at the call site of my method. All these extra heap chunks slow down the check for permissions when inhaling the postcondition of my method. However, I don't think there is any reason these permissions need to be checked since they've just been inhaled by the postcondition and the method itself has already been verified. (and that verification of the method itself was really fast because the method only deals with a handful of heap chunks)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants