[LLVMdev] RegisterAnalysisGroup

[David A. Greene]

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

Yep, I understand that too.  But it isn't working for register
coalescing for some reason.  That's what I'm trying to figure
out and it's pretty tough.

>> This PassManager stuff is extremely confusing and not well documented.
> 
> Hrm?
> http://llvm.org/docs/WritingAnLLVMPass.html

That doesn't document the implementation at all.  It's a good high-level
document about how to register a pass with PassManager but doesn't say
anything about the underlying mechanism.  It's not a document useful
for debugging problems beyond mentioning --debug-pass.

There's a lot of tricky global constructor stuff going on to register
passes, parse options, etc.  Every time I have to work in this area
it's hard.  That's been my experience.

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

I have.  Several times.  The benefits claimed for PassManager are:

1. Share analysis results

This is basically tracking when analysis information goes out-of-date.

2. Pipeline the execution of passes on the program

This isn't really a PassManager benefit.  Every single compiler I've
ever worked with does this.

Another benefit not explicitly listed is the running of prerequisites.
But again, we don't need anything as complicated as PassManager to do
that.  The whole schedulePass, listener, command-line interactions
are extremely complex and esoteric.

Now, dynamically loaded passes do need some kind of registrar, but it
can be much simpler than the existing PassManager implementation.

I'm not disagreeing that we want an object to manage passes.  But the
implementation strikes me as much too complex for what it actually does.
We definitely want a pass manager.  I'm just not sure we need
PassManager.

                                  -Dave