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
Executing a function may have a cumulative effect on the state guard. For example, if the
callee contained ASSUME statements that rendered one or more control-flow options unviable
then the guard might still embody that restriction (i.e. for if(x) ASSUME(false) the guard might
still be `!x`). However, on function return we know that all control-flow paths have converged
or been shown to be unviable, so we can restore the simpler guard as it was when we entered
the callee function.
Exceptions:
(a) if the guard is false it would be correct but inefficient to restore it; keep it false until
we find a convergeance with another viable path
(b) if we're doing path-sensitive symex then we do tail duplication, and there are no control-flow
convergeances. Keep the guard as-was.
(c) if we're executing a multi-threaded program then symex_assume_l2 uses the guard to accumulate
assumptions, which we must not discard.
In truth this optimisation is applicable whenever a block postdominates another, but function
structure gives us a cheap way to establish postdominance without analysis (in the absence of
setjmp/longjmp at least)
0 commit comments