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

[Tobias Grosser]

On 06/21/2012 03:59 PM, Joshua Cranmer wrote:
> 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.

Great to get an update on the general direction here. I like it a lot, 
but will now stop the discussion to allow us to focus on the review of 
this patch.

I did not state it before, but from my side it looks good style and typo 
wise, but I am by no means familiar with clang and can consequently not 
review it.

>> 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.

Yes, it is actually not so easy to solve. If you find a solution, it 
would be great if it could also be applied to the LLVM plugins.

>> 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.

I was looking into this myself and it seems non trivial. Still, I think 
it would be nice to have.

Looking forward to see your further work
Tobi