Re: Progress on GCC plugins ?

[Chris Lattner <clattner at apple dot com>]

On Nov 24, 2007, at 1:54 PM, Alexandre Oliva wrote:

> On Nov 16, 2007, Basile STARYNKEVITCH <basile@starynkevitch.net>  
> wrote:
>
> > For example, the "simple" plugin mechanism many people have  
> > implicitly
> > in mind is just: something give you the ability to call a dlsymed
> > function inside a dlopened plugin as a pass in a defined (& fixed)
> > position in passes.c. I tend to believe it is not that difficult to
> > implement (it seems to me that the issue is to get it accepted in the
> > trunk). However, this does not guaranty at all that all the internal
> > representation (e.g. the tree.h and other header files) is stable.
>
> Exactly.  And I guess some of this could even be accomplished with
> LD_PRELOAD.  But how useful would that be, really?  How far would this
> go into addressing the real needs that are behind the requests for
> plugin support?

Full "plugin support" really encompasses more than having GCC just  
being able to dlopen a .so file.  It means providing (hopefully) well  
defined extension points for common operations.  For example, it  
should be relatively easy to load a plugin that defines a new tree-ssa  
pass, and have it get dropped naturally into the pass manager.   
Alternatively, you could have an extension point for "gimple  
consumers" that don't care about the optimizer or backend, but just  
want a way to parse the code and deal with the gimple or generic  
trees.  Examples of this would be static analysis tools or things like  
the "FFI generator" for scripting languages.

To me personally, I'm looking forward to this happening because it  
means that "llvm-gcc" could conceptually just become a plugin into a  
standard GCC: the llvm-gcc plugin would use exactly the same extension  
point as the "static analysis tools" (it doesn't care about the GCC  
optimizer or backend, so it just wouldn't use it).  This would make it  
potentially easier to deploy the llvm-gcc binary (it's a plugin for a  
specific gcc, instead of an entire copy of gcc itself), and it would  
potentially make it easier to keep the tree up to date as GCC moves  
forward.  For the record, I'm fine everything being GPL, the license  
is not the issue.

-Chris