[LLVMdev] Analysis Passes

Devang Patel dpatel at apple.com
Fri Jul 25 12:01:11 PDT 2008


On Jul 25, 2008, at 10:56 AM, Marc de Kruijf wrote:

> Could somebody please explain exactly what an "analysis pass" is?   
> I've spent some time trying to understand this and I just don't get  
> it.  Right now my understanding is the following:  if a pass is an  
> "analysis" pass, the "print" function is called when giving the "- 
> analyze" switch to opt.

Yes.

> Is there more to it than that?

Analysis pass collects information that is used by other passes, for  
example alias info., loop info, dominator info etc..

> If I've got it wrong, here are some potentially clarifying questions:
>
> 1.  If a pass is an analysis pass, does it necessarily not alter the  
> CFG?

Yes, Analysis passes do not alter CFG.

> 2.  Does a pass need to be an analysis pass if it is used by another  
> pass calling getAnalysisUsage?

The other passes uses getAnalysisUsage() to access information  
collected by an analysis information. getAnalysisUsage() interface  
should not be used to order transformation/code generation passes.  
There are couple of cases where code generator violates this and I'd  
like to eventually fix it.

> 3.  How does whether or not a pass is an analysis pass or not affect  
> the pass's execution?

In general it does not. Analysis pass is executed just like any other  
pass.

The distinction is important for the pass manager, who is responsible  
to automatically schedule an analysis pass if the analysis info is not  
available (or dirty) and is required by a transformation pass.

One small distinction is - pass manager will not re-run an analysis  
pass if the information is up-to-date. However, the pass manager will  
re-run a transformation pass if requested to do so.

For example,
   $ opt -domtree -domtree a.bc -disable-output
will run dominator tree analysis pass only once.
   $ opt -instcombine -instcombine a.bc -disable-output
will run instruction combiner pass twice.

-
Devang




More information about the llvm-dev mailing list