[LLVMdev] RegisterAnalysisGroup

[David Greene]

On Friday 14 September 2007 16:04, David Greene wrote:
> On Friday 14 September 2007 15:51, Chris Lattner wrote:
> > When basicaa registers itself as part of the analysis group, it uses:
> >
> >    RegisterPass<BasicAliasAnalysis>
> >    X("basicaa", "Basic Alias Analysis (default AA impl)");
> >
> >    // Declare that we implement the AliasAnalysis interface
> >    RegisterAnalysisGroup<AliasAnalysis, true> Y(X);
> >
> > The "true" says that it is the default,
>
> Right, I get that.  My question is how a pass that requires AliasAnalysis
> gets Andersens when -anders-aa is passed on the command-line.
> Someone has to call setNormalCtor on the PassInfo for the AliasAnalysis
> group but I can't fgind that code anywhere.

Hmm, I'm not quite correct here.  I seem to recall someone at some point 
saying that when searching for a member of an analysis group, the first
implementation constructed will be used.

Is the searching code implemented by AnalysisResolver::findImplPass?

> I'm debugging some analysis group code and I instrumented the
> registration constructors.  I see weird things like this:

Just FYI, llvm's version of cerr, et. al., won't work in constructors called
during program started because <iostream> isn't included in those
files and therefore might not be constructed yet.

I believe the same problem is the reason that some alias analysis 
passes are constrcuted before the AliasAnalysis analysis group is
constructed.  There's no mechanism to determine order of construction.

I still don't understand how constructing members of an analysis group
before the analysis group is constructed can work at all.  Oh, I guess this
clase in RegisterAGBase's constructor  takes care of it:

  InterfaceInfo = const_cast<PassInfo*>(Pass::lookupPassInfo(InterfaceID));
  if (InterfaceInfo == 0) {
    // First reference to Interface, register it now.
    registerPass();
    InterfaceInfo = &PIObj;
  }

Is that right?

This PassManager stuff is extremely confusing and not well documented.  Does 
it really buy us all that much?  I can't believe there's much room for 
rescheduling passes unless llvm actually reschedules optimizations, which
would be *very* bad indeed.  Otherwise, isn't PassManager just keeping
track of when analysis information is invalidated?  If so, we just need a 
bitvector for that, no need for all this fancy registration code.

                                               -Dave