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

[David Chisnall]

On 22 May 2011, at 00:13, Chris Lattner wrote:

>> 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.  
> 
> I don't understand what you mean here.  Plugins are inherently tied to the frontend they are plugging into, and I don't see how that is related to tight coupling between frontends and optimizations.

LLVM plugins do not plug in to front ends, they plug in to LLVM.  A pass defined in a plugin has no awareness of any specific front ends - it just transforms IR.  Currently we have to load them explicitly, but the next thing on my LLVM TODO list is providing a mechanism for LLVM to automatically load plugins.  The goal is to be able to just install a new plugin via your normal package manager and have installed LLVM-based compilers automatically take advantage of it.

The entire point of my changes was to avoid the NxM problem where you need special code for every optimisation / consumer combination.

>> 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.
> 
> Doing this though global variables is a non-starter to me.  It violates the entire spirit of llvm as a library.  It seems perfectly reasonable to define a plugin API that doesn't require tight frontend knowledge *or* global variables, but it would require some implementation effort.  Just dropping in a bunch of global variables isn't the way to go.

I'm not really sure that I see the problem with that.  If static initialisers are really an issue, then we can always move to a more lazy initialisation mechanism, but we still need some mechanism for plugins, when loaded, to add their passes to the standard list.  

> I added the extension point mechanism, please review it and propose some specific new extension points that will do what you need.  Thanks David, StandardPasses.h has long needed a good cleanup.

I've had a quick look, and I'm still not seeing how it addresses the problem.  How does it allow an LLVM plugin to modify the set of default passes that are returned to optimisation consumers?  

Your code looks reasonably clean, but doesn't seem to address the problem.  We now have a list of extension functions, but no way for plugins to modify that list.  

David