getting visit methods right


I have overridden VisitIfStmt(Stmt* s) and some visit methods for binary operators:
- VisitBinAssign(),
- VisitBinAdd() and other arithmetic operators,
- VisitBinGT() and other relational operators

My dilemma is how do I return from different visit methods (or call them explicitly)
so that I can perform some analysis on binary operators and use them in condition part,
then clause and else clause for IfStmt? e.g. I want to analyze following C program:
int main() {
     int x, y;
     x = 10;
     if (x > 0)
         y = 1;
     else if (x == 0)
         y = 0;
         y = -1;
     return 0;

Basic block contains:
    1: int x;
    2: int y;
    3: x = 10
    4: x > 0
    T: if [B6.4]

Now, for condition x > 0 (line 3:) due to VisitBinGT() can get following info:
         Relational Op >
         LHS identifier = x
         type: int
         RHS value: 0
From VisitIfStmt() I can get pointer to condition part, then and else clauses.
so, how should I combine IfStmt and information I have due to visit to other methods?

Please advise.

- Rajendra

Any suggestion on this topic, please?

- Rajendra

Write a static analyzer plugin instead.

The RecursiveASTVisitor interface is for syntactic checking; it won't be able to do a good job with propagating information forward with, say, loops. If you're looking for a "fast" flow-sensitive analysis, Sema's AnalysisBasedWarnings shows how it's done, but if you want more precision in actually determining which paths are feasible, you're going to need the full power of the static analyzer. You're basically reinventing the entire analyzer core if you're trying to track the flow of data from assignments to conditions and then to which branch is taken.

Unfortunately, the documentation on how to write a static analyzer "checker" is still a bit limited, but you can find information at and the slides from our talk at the LLVM Develeopers' Meeting at


Hi Jordon,

Are you saying that using visitor methods of RecursiveASTVisitor is not correct way for static analysis of conditions (if-else) and loops (while)? or not recommended?

That’s correct. It’s the difference between reading your program and running it.

What about getting control flow information from successors of a basic block for IfStmt, WhileStmt from CFGTerminator? I think this is the way basic blocks in CFG keep information about control flow. Please correct me if this doesn’t sound good.

Yes, that’s what the CFG is for, and you can use that for flow-sensitive warnings (and we do). However, no path-sensitive information persists; that is, the CFG is perfectly happy to say you can go down both if-conditions here.

if (x > 1) {
if (x < 0) {

Again, AnalysisBasedWarnings has some very simple logic to do a little of this, but if you actually want to simulate program execution, that’s what the static analyzer is for.