[LLVMdev] RegisterAnalysisGroup

[Chris Lattner]

On Sep 14, 2007, at 2:46 PM, David Greene wrote:

> 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?

Consider a pass manager queue like this:

-gvn

In this case, the passmanager goes to add GVN and sees that gvn  
requires alias analysis.  However, alias analysis is not already  
available.  As such it creates an instance of the default impl,  
producing:

-basicaa -gvn

Consider the passmanager running on a queu like this:

-no-aa -gvn

In this case, -no-aa does not require anything so it gets added to  
the queue.  no-aa provides the AA analysis group.

Next step, GVN is added.  As above, -gvn requires alias analysis.   
The passmanager sees that AA is already available, so it uses it  
instead of adding an instance of basicaa.  This yields:

-no-aa -gvn

This is exactly by design.



>> 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.

Right.  The only reason you should want to do this is because of  
debugging.  For local debugging purposes, it's fine to use <iostream>  
obviously.

> 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.

This shouldn't be required.  The analysisgroup is created on demand.

> 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?

Yes.

> This PassManager stuff is extremely confusing and not well documented.

Hrm?
http://llvm.org/docs/WritingAnLLVMPass.html

> Does
> it really buy us all that much?

Yes.

> I can't believe there's much room for
> rescheduling passes unless llvm actually reschedules optimizations,  
> which
> would be *very* bad indeed.

The PassManager does a lot of stuff, plz read the docs.

> Otherwise, isn't PassManager just keeping
> track of when analysis information is invalidated?

No.

-Chris