[cfe-dev] Proposed: change tracking for RegionStore

[Jordy Rose]

On Mon, 2 Aug 2010 17:33:43 -0700, Ted Kremenek <kremenek at apple.com>
wrote:
> This is essentially what we are trying to do.  The problem is whether
that
> map is done as a per-path property or something "global" to the instance
of
> a Checker or GRExprEngine.  If it is per-path, the map has to go in
GRState
> or something similar if that map isn't short-lived.  My suggestion
before
> was that this map is essentially implicitly defined by the Checkers,
since
> they are already tracking checker-specific state on the side.  In this
> case, representing this map separately in GRState seems a little silly
to
> me, and potentially a performance concern when it comes to state
caching.

Tracking the map in GRState is probably worse than change markers when it
comes to merging state, so I agree that a path-sensitive map wouldn't buy
us much. The difference between having an explicit map and an implicit one
is really just a time/memory/simplicity tradeoff.

These are the options I see:

Explicit map :
- One place to deal with super-regions.
- No virtual calls except for the checkers who actually said they were
interested.
- Backing (proposed): DenseMap<const MemRegion *, vector<Checker *>>

"Interest poll":
- Before each modification, ask checkers if they're interested in the
change.
- After the modification, notify all checkers that said they were
interested.
- If we wanted, this would let us ask checkers about certain /kinds/ of
changes.
- Downside: (up to) twice as many calls.

ProcessRegionChange:
- Like ProcessAssume, does no filtering of checkers. Takes a GRState and
the location that changed (SVal or MemRegion?), returns a new GRState.
- Not too hard to add the same sort of respondsToCallback checking as for
Visit*Stmt, meaning we'd at least only get checkers that /can/ track region
changes.
- Downside: not context-sensitive at all.