No shortcut for narrow and meet in HConsed when int refinement is active#1186
No shortcut for narrow and meet in HConsed when int refinement is active#1186michael-schwarz merged 3 commits intomasterfrom
narrow and meet in HConsed when int refinement is active#1186Conversation
|
This essentially just ignores the issue in the int domains (specifically the reduced product of them) instead of fixing it. I don't think this is the right solution because it still violates the narrowing property Before this, What it essentially means is that a stable sequence might become unstable out of nowhere, instead of remaining ultimately stable. Therefore, the TD3 termination proof falls apart. |
|
Ok, we can argue that this should not close the issue then, and the issue should be renamed ("invalid narrowing in the presence of refinement" or something). However, I still think it is an improvement: The main thing this currently does is make the behavior consistent between having hash-consing on or off. Hash-consing should be a performance optimization only, there should not be any difference observable between the case where it is enabled or disabled. This conflates issues unnecessarily. The point where your concern applies is immediately when we define the meet and narrow to refine, violating the properties you described above. Hashconsing accidentally fixing that again is not really the way to go. Edit: Might also be interesting to see to what extent it is relevant that the concretizations remain the same in both cases. |
|
Relevant paper by Cortesi: https://www.dsi.unive.it/~cortesi/paperi/CL_2011.pdf |
|
Actually, That narrowing property is just what implies that one step stability means ultimate stability. |
|
Merging this as per discussion at the GobCon yesterday. |
|
|
||
| (* We do refine int values on narrow and meet {!IntDomain.IntDomTupleImpl}, which can lead to fixpoint issues if we assume x op x = x *) | ||
| (* see https://github.com/goblint/analyzer/issues/1005 *) | ||
| let int_refine_active = GobConfig.get_string "ana.int.refinement" <> "never" |
There was a problem hiding this comment.
It should not be too expensive, as a local boolean to cache this information is introduced.
This is immediately evaluated though, not a ResettableLazy/ref. A properly dynamic value already exists as IntDomain.get_refinement, so we should just reuse that.
There was a problem hiding this comment.
This module is constructed dynamically though, so it is not really a problem here.
As @sim642 noted in #1005, int domain refinement (which we do not only after transformers, but also after
meetandnarrow), breaks the assumption thatx op x =xfornarrowandmeet.This disables the shortcut in
HConsedfornarrowandmeetwhenever an int refinement is active, and its precondition is not met. It should not be too expensive, as a local boolean to cache this information is introduced.Closes #1005.(#1005 also mentions a different but related issue that refinement could be applied more often still, but I think this we can save for a separate PR, this PR fixes the immediate issue and makes refinement usable together with hash consing).