[llvm-commits] [llvm] r131581 - in /llvm/trunk: include/llvm/DefaultPasses.h include/llvm/Support/StandardPasses.h lib/Support/StandardPasses.cpp

[David Chisnall]

On 21 May 2011, at 21:53, Chris Lattner wrote:

> Lets keep your patch in until we have a chance to resolve this.  I assume that you're doing your work in the context of dragonegg?  If so, can you switch dragonegg over to the new PassManagerBuilder?

I'm not using dragon egg at all, although some of the passes that I've written can be used with it if you are compiling Objective-C code.

My point was that there should be no tight coupling between the front ends and the optimisations at all, because then you need one plugin for every front end that might use the passes, which adds silly amounts of complexity.  The aim is to have an interface for plugins provided by LLVM and an interface for front ends / things that drive optimisations provided by LLVM, with the former controlling the semantics of the latter.

I also aimed to keep the existing front end API, because making every front end author rewrite how they drive the optimisation system is just going to irritate people.

> I think that the best way to handle the plugin extensibility problem is to pick the interesting extension points (places where plugins can add passes), and add something like this:
> 
> enum PMExtensionPointTy {
>  EP_LatePerFunctionPasses,
>  EP_EarlyPerModulePasses,
>  ..
> };
> 
> Then plugins can add an API like this:
> 
> PMBuilder.addPassExtension(EP_LatePerFunctionPasses, addMyLatePerFunctionExtensions);

I think that makes sense.

> Where addMyLatePerFunctionExtensions is declared as something like this:
> 
> void addMyLatePerFunctionExtensions(const PMBuilder &Builder, PassManagerBase &PM) {
>  if (Builder.getOptLevel() > 2 && Builder.getOptSizeLevel() == 0)
>    PM.add(createMyPass());
> }
> 
> Would something like this work for you?  What are the places that you'd like to add passes, specifically?

Yes, I think that works for me.  The interface is clean, and it gives plugins fine-grained control over which optimisations are added.  I think it would also be interesting if the PMBuilder had could store some extra information, such as the language (or languages) used in the front end, although I'm not sure how that would work with LTO (maybe via some module-level metadata?).  I can imagine some optimisations that would only make sense for C++, for example, so a Python front end wouldn't want to run them but both clang and DragonEgg would when compiling C++ (but not necessarily when compiling C).  

I think there are thee places where I might want to add passes:

- Right at the start, when the code is as close to the source language as possible.
- When the basic analysis and simplification stuff has run.
- Near the end

David