Merged
Conversation
Expcompare.compareExp does additional transformations which are incompatible with the rest of compare. This causes incorrect behavior in sets.
ValueDomain.determine_offset assumed CilType.Exp.equal would do constant folding in Expcompare.compareExp.
9319a3a to
ebf49aa
Compare
michael-schwarz
approved these changes
Sep 1, 2022
Member
Author
|
Merging of this depends on #809, which should also fix gobview properly. |
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
hopefullyfixes all remainingERROR (verify)results on sv-benchmarks (Full table).It is on top of #809 since that causes significant changes to
ERROR (verify)results.Changes
CilType.Exp.compare(and alsoCilType.Exp.equal) previously called CIL'sExpcompare.compareExpto check for equality (confusingly not anintcompare value) before falling back to the generalcomparelogic implemented there.Expcompare.compareExpdoes some strange things though: it implements only few basic cases and falls back to trying to constant fold both arguments. Such logic is completely inconsistent with everything else inCilType.Exp, which doesn't do similar things for its owncompareandhashlogic, but which must have consistent behavior.In particular, this affected var_eq analysis's expression partition sets, which use
compare. The problem is that in non-constant-fold-equal cases the ordering defined by our general logic doesn't account for the equivalences induced by constant folding for equality.All the verify errors in "ufo" benchmarks are about def_exc ranges for booleans. Under some unpredictable conditions, that range could unnecessarily worsen from
[0,1]to[0,7].The problem seems to be
GoblintCil.intKindForValue, which claimsExcept it doesn't always return the smallest kind: for 0 and 1 that should be
IBool, notIUChar.Currently I made the fix in Goblint to quickly debug and benchmark the issue, but it should probably be ported over to CIL.
TODO
intKindForValueforIBoolcil#111.