You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
kontrol merge-nodes can run into an issue where one branch simplifies an expression and the other doesn't, which causes problems when the two branches are merged. For example, the following happens when trying to use it for the test in PR #162:
One of the side conditions C in our configuration contains the subexpression X modInt 2 ==Int 0.
We branch on the condition X /Int 2 ==Int 0.
In the branch where X /Int 2 ==Int 0, X modInt 2 ==Int 0 can be simplified to X ==Int 0. This turns C into a different side condition C'.
In the branch where X /Int 2 =/=Int 0, the simplification doesn't apply, so it remains as C.
As a result, when we merge the two nodes, instead of getting C #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) ) (where B and B' are the constraints that are different between the two branches) we instead get ( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) ).
Because this can happen when C is alread a merged expression like (P andBool Q) orBool (notBool P andBool Q'), this can quickly compound over multiple applications of merge-nodes and grow into a large unreadable expression with multiple nested andBool and orBool operators.
What can we do about this?
While we can write a lemma to turn ( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) ) back into C #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) ), this lemma is both very complex and very non-generalizable (we would need to write a different lemma for every case). So this approach doesn't seem ideal.
If we were able to specify what we want our merged node to look like, Kontrol should be able to determine that it subsumes both of the individual nodes being merged. This is similar to a loop invariant, and if we implement a way to specify loop invariants as annotations in the Solidity code, that functionality can probably also be used for this.
The text was updated successfully, but these errors were encountered:
kontrol merge-nodes
can run into an issue where one branch simplifies an expression and the other doesn't, which causes problems when the two branches are merged. For example, the following happens when trying to use it for the test in PR #162:C
in our configuration contains the subexpressionX modInt 2 ==Int 0
.X /Int 2 ==Int 0
.X /Int 2 ==Int 0
,X modInt 2 ==Int 0
can be simplified toX ==Int 0
. This turnsC
into a different side conditionC'
.X /Int 2 =/=Int 0
, the simplification doesn't apply, so it remains asC
.C #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) )
(whereB
andB'
are the constraints that are different between the two branches) we instead get( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) )
.Because this can happen when
C
is alread a merged expression like(P andBool Q) orBool (notBool P andBool Q')
, this can quickly compound over multiple applications ofmerge-nodes
and grow into a large unreadable expression with multiple nestedandBool
andorBool
operators.What can we do about this?
( ( X /Int 2 =/=Int 0 andBool B andBool C ) orBool ( X /Int 2 ==Int 0 andBool B' andBool C' ) )
back intoC #And ( ( X /Int 2 =/=Int 0 andBool B ) orBool ( X /Int 2 ==Int 0 andBool B' ) )
, this lemma is both very complex and very non-generalizable (we would need to write a different lemma for every case). So this approach doesn't seem ideal.The text was updated successfully, but these errors were encountered: