[cfe-dev] Proposed: change tracking for RegionStore

[Ted Kremenek]

On Aug 11, 2010, at 9:38 PM, Jordy Rose wrote:

>> With the reference, it just seems like we must pay the cost of this
> every
>> time we use InvalidateRegions.  If there are no checkers that consume
> this
>> information, we always pay the cost.  That's the reason why
>> InvalidatedSymbols is a pointer.
> 
> Makes sense. Here's a version using a pointer and a check beforehand to
> see if any regions are interested. The whole WantsRegionChangeUpdate
> structure seems awkward to me, though. It's not being called for bindLoc()
> and bindDefault() because it doesn't have any benefit there, and checkers
> that return false from WantsRegionChangeUpdate can still be called for
> ProcessRegionChanges if some other checker wants an update. Which,
> unfortunately, means we can't promise checkers that ProcessRegionChanges
> won't be called even if they don't want the update.

I think this is good enough for now to get into the tree so that we can start playing with it.

> 
> I suppose we could make a list of checkers that were interested and use
> /that/ later on. If we did that, though, we'd have the odd case of
> ProcessRegionChanges taking an array of checkers as an argument. We could
> move the whole invalidation logic from GRStateManager into GRSubEngine, but
> most of it really isn't engine or checker logic -- it's just
> store-and-state code like all the others.

This seems like an optimization we can investigate in the future, but I think it's good to keep things simple for now.  We're getting a lot of moving parts with these callbacks, and since the design of this feature isn't completely understood I'm fine with keeping it a little "sub-optimal" for now.