-
Notifications
You must be signed in to change notification settings - Fork 109
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
use old
in trigger for direct array assignments
#888
Conversation
…iperproject#877. remove auxiliary helper function for `selection_sort.rs` viperproject#819. added regression test for viperproject#877.
I have opened a Silicon issue viperproject/silicon#603. Before we merge this PR, let's see what the Silicon developers think. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this is a Viper backend bug and we could merge this workaround until it is fixed.
Thanks for the feedback @vakaras! I will address the requested changes some time tomorrow :) |
…out unresolved sillicon issue
(The requested changes are ready and have been pushed just now, fyi.) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thank you!
bors r+
This PR experiments with addressing 2 things:
selection_sort.rs
test case was updated to use this fix in order to remove the auxiliaryset
function (verify/pass/arrays/{merge,selection_sort}.rs
timeout issue #819).Some notes apply to the approach chosen to make
selection_sort.rs
verify:body_invariant!(a[0] <= a[i]);
was added to the outer and inner loops in order to correctly trigger the quantifiers.prusti-viper/src/encoder/foldunfold/mod.rs
to prevent Prusti from running into an encoder error when theold
expresion was only present in the trigger, but not in the quantifier body. Without this change,selection_sort.rs
will complain about a fold-unfold error. Since access predicates are not needed when theold
expression is only present in the trigger, this should be sound (but please do double check this during the peer review).set
function, the verification time roughly doubled, but it is still well within the-Pverification_deadline=180
compiler parameter. Execution time now hovers around ~2 minutes on my PC.If the chosen approach sounds good, then this PR can be merged. I'm still a bit suspicious about why the
set
function yields better performance, I could look into this deeper with some guidance (possibly in a separate PR if that makes more sense). For now I came up empty-handed for what could be causing this performance regression (if this happens to be related to how Viper gives hints to Z3 based on the Viper/Silver syntax, then my current experience may not be of much help, but am willing to learn more!).Thanks!
p.s. Issue #877 can be left open for now in case we want to file a bug report with the Viper back-end developers to investigate the
old
trigger issue. I posted a ~30 lines example there that hopefully is small enough to investigate.