[cfe-commits] r137309 - in /cfe/trunk: include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h lib/StaticAnalyzer/Core/SymbolManager.cpp

[Ted Kremenek]

On Aug 11, 2011, at 3:04 PM, Jordy Rose wrote:

> I'm curious what the motivation was for choosing to store the symbols as Base -> [list of dependents] instead of Dependent -> Base. I doubt many symbols are going to have multiple dependents, especially when they're being ORed together instead of ANDed. I realize that it makes it easy to clear the map when the base symbol dies, but since every dead symbol sweep hits every symbol anyway that doesn't seem to be a problem. (SymbolDerived works the other way around.)

I think you have a good point.  Going from base to dependents instead of dependents to base is probably more eager than we need to be.  We only need to care if a dependent's lifetime is extended if we think it might be dead.  If a dependent looks dead, lazily querying to see if a the base symbol is live seems slightly more efficient to me.

Anna: what do you think?

As for not many symbols having multiple dependents, I don't think that's a valid assumption.  The whole point of this addition was to give checkers the ability to tie two symbols together (e.g., parameter out value and a return value).  There's no reason why there can't be multiple dependents.  Even if it's just two checkers that need to track dependencies between a common symbol and another, two is still more than one.

> 
> Also, separate from implementation, would it be worth it to use this to /implement/ SymbolDerived? They're basically SymbolRegionValues with dependencies.

Yes, I had the same thought.  That would be a nice cleanup.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110811/c13191a3/attachment.html>