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

[Chris Lattner]

On May 22, 2011, at 3:21 AM, David Chisnall wrote:
>> The frontend is still responsible for loading the plugin. Is there any reason we can't define an API for plugins that we look for and have the frontend pass the plugin PMBuilder object to manipulate? It means that supporting plugins that modify code generation becomes opt-in for the llvm-using program, but it we do that once per frontend and don't need to worry about dealing with every possible frontend-plugin combination.
>> 
>> Making it opt-in would be much preferred, actually.
> 
> The more I think about this, the more I come to the conclusion that the correct solution is to properly define the plugin interface.  Currently, we basically just dlopen() a plugin and expect static constructors in the plugin to do everything.  This makes means that all interaction works with code flow from the plugin to the main program, which is a bit counter intuitive.

Yes, I completely agree that we need a proper plugin interface.  That interface can include things like "hey plugin, here is my PassManagerBuilder for you to hack on".  I think that a proper plugin interface is vastly preferable to a dlopen style interface.

> I wonder if the correct solution is to define an llvm::PluginRegistry or similar.  This can collect plugins, loaded both from command-line options and from a config file, and provide a unified entry point for invoking plugins.  We then construct the PluginRegistry in the tools, and (optionally) pass a reference of it to the PassManagerBuilder, and to anything else that wants to provide hooks for plugins.

I think it makes sense to have an llvm::Plugin interface that specific plugins can implement (and would have methods like "hack on this PassManagerBuilder").  Plugins will eventually want to get some sort of command line option info as well, which can fold into this interface.  It would make sense for frontends to be able to subclass this as well, so a clang specific plugin could implement clang::Plugin, which derives from llvm::Plugin but is able to get access to other clang-specific stuff.

Once you have a set of plugins, we'll need a registry of some sort.  The registry can be global, but it should hold pointers to constructor functions for the plugin, not instances of the plugin themselves.  A static constructor (run when the plugin is dlopen'd) can add the plugin constructor to the registry.

-Chris