[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