[LLVMdev] RegisterAnalysisGroup
David Greene
dag at cray.com
Fri Sep 14 14:46:09 PDT 2007
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
More information about the llvm-dev
mailing list