[cfe-dev] [analyzer] Zombie symbols.

[Anna Zaks via cfe-dev]

> On Mar 25, 2016, at 7:18 AM, Artem Dergachev via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> > At which point is the symbol removed from the state? It that a
> > byproduct of the store?
> 
> Well, yeah, i guess it's probably even "the primary product" - to erase the original value while overwriting. And once the original value is erased, it's no longer referenced.
> 
> > > 1. Scan all symbols in the SymbolManager to find zombie symbols,
> > > deprecate the maybeDead() mechanism.
> > > 2. Wait until some kind of smart data map takes care of this extra work.
> 
> > Are you talking about a data structure that keeps track of the
> > data stored by the checkers. Presumably, that could be scanned
> > to find out which symbols are tracked by the checkers? This
> > direction looks the most appealing at this point.
> 
> Seems so; why i'm also thinking of "1." is because i feel it'd make removeDeadBindings sooo much easier to understand and sooo much more intuitive - which it seems to need, as even an issue as simple as this one had remained unnoticed. It seems that everybody was thinking that "1." is already there. "The garbage collector was supposed to see which symbols are referenced and remove those that aren't, how else could it work?" In this case, we probably wouldn't even need a worklist [which currently iterates only through the store, but also needs to iterate through the GDM at the same time, as there may be mutual dependencies between symbols here and there] during garbage collection, just rely on later iterations to clean up sub-symbols step by step. So i'd probably give it a try some day and try to explain it in more details if something useful shows up.
> 
> Though i've no idea about performance; the wordlist would most likely still have better performance.
> 

Craig is right, performance of the analyzer is very sensitive to removeDeadBindings.

> And also, if we make a new API for the data map, the old API might still want to be fixed somehow.

We could rewrite all of the checkers to use the new model if it was flexible enough. (Also, the old checkers won't be broken, they will juts not benefit from the improvement; will have false negatives.)

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev