Defining a common plugin machinery

[Chris Lattner]

On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:

> Basile STARYNKEVITCH <basile@starynkevitch.net> writes:
>
>> I am much more worried about passes and plugins (and I am very
>> surprised to be almost the only one mentioning passes in plugin
>> discussions). I feel it is a major issue (not a matter of coding,  
>> much
>> more a matter of convention & understanding). So far, I have (in MELT
>> branch) a very unsatisfactory bad solution. I defined a few passes,
>> which may (or not) be enabled by some plugins. What I would dream is
>> some machinery to be able to have the plugin ask 'insert my pass
>> foo_pass after the last pass which construct the IPA SSA tuple
>> representation' and this is not achievable today.
>
> I think we also need that for general backend use, not only for
> plugins.  E.g., bt-load.c should move to config/sh, and at startup
> time the SH backend should register the pass with the pass manager.

Is the plugin machinery intended to eventually allow new (GPL  
compatible) backends to be used?  It would be nice to make llvm-gcc be  
a plugin.

-Chris