[cfe-dev] Removing "TransferFuncs" from the analyzer

Jordy Rose jediknil at belkadan.com
Thu Jul 14 21:11:15 PDT 2011


Separately, there is one last thing CFRefCount does that I missed my first time around: it determines whether we're running a GC or non-GC analysis when we're in a hybrid mode. This is something that has to be dealt with at the same time as moving what's currently in evalCall and evalObjCMessage to RetainReleaseChecker.

Now, we could just move the flag to AnalysisContextManager or ExprEngine, but neither of those feel right — is this ever going to matter to anyone besides RetainReleaseChecker? (Currently it's limited to CFRefCount.cpp.)

My alternative is to bifurcate the GRState at the start of each code body. This limits the split to when RetainReleaseChecker is active. We could even go further and make it split the state on demand, with something like this:

> std::pair<const GRState*, const GRState *> splitGC (const GRState *state) {
>   switch (langOpts.getGCMode()) {
>   case LangOptions::NonGC:
>     return pair(state, NULL);
> 
>   case LangOptions::GCOnly:
>     return pair(NULL, state);
> 
>   case LangOptions::HybridGC:
>     // See if we've picked a mode yet. If not, the default is HybridGC.
>     switch (state->get<GCEnabled>()) {
>     case LangOptions::NonGC:
>       return pair(state, NULL);
>     case LangOptions::GCOnly:
>       return pair(NULL, state);
>     case LangOptions::HybridGC: {
>       const GRState *withoutGC = state->set<GCEnabled>(LangOptions::NonGC);
>       const GRState *withGC = state->set<GCEnabled>(LangOptions::GCOnly);
>       return pair(withoutGC, withGC);
>     }
>     }
>   }
> }
> 
> // later...
> llvm::tie(stateNoGC, stateGC) = splitGC(state);

That way, it'll choose whether or not to analyze a function under GC as soon as it needs to, but no sooner. (Since this is an optimization, it'd be something to add after the CFRefCount migration is done.)

The downside of bifurcating states instead of running two analyses is increased memory usage; the upside is a probable minor speed benefit from only having to do path-insensitive checks once, walk the AST once, etc. And of course, less target-specific information in the analyzer infrastructure.

We can hold off on this piece for a while longer, though. :-)

Jordy





More information about the cfe-dev mailing list