[cfe-commits] [PATCH] Implement a better plugin API for clang

Joshua Cranmer pidgeot18 at gmail.com
Thu Jun 21 06:59:44 PDT 2012


On 6/21/2012 8:17 AM, Tobias Grosser wrote:
> On 06/20/2012 11:58 PM, Joshua Cranmer wrote:
>> diff --git a/docs/ClangPlugins.html b/docs/ClangPlugins.html
>> --- a/docs/ClangPlugins.html
>> +++ b/docs/ClangPlugins.html
>
> Hi Joshua,
>
> I am not a regular contributor to clang, but I am following the plugin 
> infrastructure development and I must say I like the general 
> direction. My use case are no frontend plugins, but a plugin to drive 
> the Polly optimizer. What I would like clang to support is:
>
> - Allow the insertion of linker flags such as '-lgmp' from a plugin
> - Allow the insertion of '-mllvm -flag' style parameters to change the 
> LLVM default behaviour.
> - Shorter plugin parameters in the style of -<plugin-name>-<argument>. 
> E.g. '-polly-vectorize'.
>
> I know this is not the goal of this patch, but this gives the context 
> from which I look at it.

This patch in particular is primarily intended to introduce a plugin API 
which is feature-compatible with the -load/-plugin-add setup, with the 
exception that running plugins in lieu of regular code generation is an 
explicit nongoal (there's always libtooling or -fsyntax-only for that). 
That said, I do intend to add more features to plugins eventually. The 
ones I'm currently planning on working on:
1. Letting plugins add custom pragmas/attributes
2. Letting plugins do a more intrusive modification of the optimization 
passes run
3. Letting plugins modify the command lines for the jobs run by the 
driver (which includes, e.g., adding linker flags)

I also want to see the ability for plugins to modify the AST to be able 
to, e.g., add instrumentation that requires knowledge of the original 
C/C++ due to lossiness in IR representation, but I already know I'm not 
qualified to do this.
> Like the runtime check for the plugin version. It is definitely a step 
> forward. However, do you know what happens if some function names in 
> clang changed and the plugin still references old function names? I 
> suppose this will still give a linker error when loading the plugin. 
> So even so this is going in the right direction, it may be nice to 
> reason in future patches about a solution that gives a clear error 
> message in that case.

Er, I hadn't thought of that.
> Sounds good. Do you think at it will be possible in later patches to 
> add hooks to change the linker flags or the -mllvm flags?

Yes, it's possible, but there's an issue in that clang is separated in 
two processes (the driver and cc1). Given that the plugin is initialized 
and loaded in the cc1 process (since that's where most of the 
interesting stuff happens), to make it work would require another entry 
hook (for the driver), and would probably cause a few issues for people 
who rely on static constructors/destructors running exactly once.

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the cfe-commits mailing list