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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
