[cfe-dev] checkers: decoupling ValueManager from GRStateManager

Olaf Krzikalla Olaf.Krzikalla at tu-dresden.de
Mon Oct 25 09:01:45 PDT 2010


Hi @clang,

I'm trying to decouple ValueManager and some other classes from the 
GRState machinery. The goal is to make these classes reusable in a 
dataflow analysis framework. I've attached a patch with the sketch of a 
first step (it compiles fine, but shall serve as a reference only).
The most problematic thing is the placement of SValuator. Currently 
ValueManager holds it but I moved it to GRStateManager. Thus 
ValueManager can exist independently from GRStateManage and even 
StoreManager. In turn the SValuator now needs a StoreManager in addition 
to the ValueManager for construction.
But neither SValuator nor the classes derived from StoreManager need the 
GRStateManager anymore. Unfortunately in this first step a lot of 
GRState* pointers still appear in the interfaces of StoreManager and 
SValuator. However apparently some comments suggest that this will be 
changed anyway (e.g. StoreManager::getSizeInElements, 
StoreManager::CastResult was unused).
I had to made one functional change tough. I moved the body of 
SimpleSValuator::EvalCastNL/EvalCastL to 
ValueManager::castNonLoc/castLoc thus making these functions not longer 
configureable.
The questions are:
1. Is it OK to essentially make 
SimpleSValuator::EvalCastNL/EvalCastLnon-virtual?
2. What is the point of the SValuator class at all? Can/should it be 
removed? The interface and implementation can become a part of 
StoreManager. 3. Is it possible to remove the GRState* from the 
SValuator and the StoreManager interfaces alltogether?
4. In which direction is the checkers framework currently developed?


Best regards
Olaf Krzikalla
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: checker_1st.patch
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101025/19eada46/attachment.ksh>


More information about the cfe-dev mailing list