[cfe-dev] CFRefCount Problem #4: Hybrid GC

[Ted Kremenek]

On Aug 31, 2011, at 12:56 AM, Jordy Rose wrote:

> On Aug 30, 2011, at 20:16, Ted Kremenek wrote:
> 
>> 
>> On Aug 29, 2011, at 11:49 PM, Jordy Rose wrote:
>> 
>>> Ah. I was thinking something like this:
>>> 
>>> 1. GC Disabled
>>> a) create CheckerManager and register checkers
>>> b) run non-path-sensitive analyses
>>> c) run path-sensitive analyses
>>> 2. GC Enabled
>>> a) create CheckerManager and register checkers
>>> b) run non-path-sensitive analyses
>>> c) run path-sensitive analyses
>>> 
>> 
>> Let's call this plan A.
>> 
>>> It sounds like you're thinking:
>>> 
>>> 1. Create CheckerManager and register checkers
>>> 2. Mgr->setGCEnabled(true)
>>> a) run non-path-sensitive analyses
>>> b) run path-sensitive analyses
>>> 3. GC Enabled
>>> a) run non-path-sensitive analyses
>>> b) run path-sensitive analyses
>> 
>> Let's call this plan B.
>> 
>>> 
>>> ...and then checkers check if GC is enabled every time it's interesting, instead of once at registration time.
>> 
>> That's clearer.  I think your plan sounds cleaner (plan A).  Couple concerns:
>> 
>> (1) I still want checkers to be written so that if they want GC-specific logic, they don't need to be written as a separate checker.  For the Retain/Release checker, we can still keep conditional behavior just by passing the "GC enabled" flag to the checker at construction time.
> 
> The only thing I'm a little concerned about (again) is that if the flag lives on the CheckerManager it's not easily accessible (you have to go through the AnalysisManager). Is a shortcut in CheckerContext good enough? Not all callbacks include CheckerContexts, but many do.

I thought about this a bit over the last couple days.  I really hate the idea of CheckerManager having any notion of this flag.  It doesn't feel right at all.  CheckerManager should just be managing checkers.  It shouldn't be in the business of changing fundamental ways in how the checkers are run.

> What I'm working with looks something like this:
> 
> AnalysisConsumer -> PDC -> [TU] -> [GC/non-GC] -> AnalysisManager/CheckerManager -> [Decl] -> ExprEngine


Following on this, I had another thought (and I'm going to backpedal on what I said earlier).  There is no need for all checkers to get rerun between GC/non-GC.  For the non-ExprEngine analyses, we only need to call them once.  They have access to the LangOptions, so if they want to do something GC-specific, they can.

For the ExprEngine analyses, how about:

  AnalysisConsumer -> PDC -> [TU] -> AnalysisManager/CheckerManager -> [Decl] -> [GC/non-GC] -> ExprEngine

We can just keep the flag in ExprEngine, and have CheckerContext consult that.  At some point, all checker callbacks should have a CheckerContext object, so this eventually lead to a nice clean API.  There is also no analysis waste here.

The reason I prefer this approach is that ExprEngine is special when it comes to the hybrid GC mode.  We *know* that GC-semantics can change how the whole analysis works, so we need to run it twice.  Other non-ExprEngine analyses (if they care), can do the same thing.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110901/0a6bfb9e/attachment.html>