[cfe-dev] A plugin proposal for clang

Joshua Cranmer Pidgeot18 at gmail.com
Wed Oct 19 11:03:10 PDT 2011


On 10/17/2011 1:12 PM, Douglas Gregor wrote:
> On Oct 14, 2011, at 5:31 PM, Joshua Cranmer wrote:
>> 2. Add examples of plugins that illustrate iterating over the AST and 
>> getting IR for functions for futher passes.
>
> What do you mean by "getting IR for functions"? This makes sense if 
> you're adding a LLVM optimization pass of some sort through the plugin 
> mechanism.

Effectively, an example of how to do LLVM optimization passes via a 
clang plugin.
> One useful example would be to add an "annotate" attribute to various 
> declarations, and verify that the attribute made it through to the IR.
>
> I think it's useful to categorize the various existing and intended 
> extension points for a plugin interface. ASTConsumer and PPCallbacks 
> come to mind immediately, but what else?

Diagnostics (so plugins can add warnings/errors) come to mind quickly as 
well. I can imagine that some clever people might need to know about 
some specific codegen details if they are using plugins to generate 
reflective metadata; everything else I can think of is more or less 
covered by LLVM.
>> 4. No guaranteed of API or ABI compatibility between different 
>> versions of clang; the onus is on the plugin to figure out how to 
>> support multiple versions. Note that this implies that a version 
>> macro is needed to report the version of clang/llvm that the plugin 
>> is being compiled for.
>
> We'll want some API/ABI compatibility at the plugin interface layer 
> (just for the entry points), but otherwise I agree fully. We don't 
> want the existence of plugins to keep us from doing refactoring of the 
> ASTs or other core data structures.

For the moment, I had thought of merely making the existing 
infrastructure (clang::FrontendPluginRegistry) easier to use, but, on 
reflection, it seems a better idea to do a more proper initialization 
approach. The minimal approach amounts to declaring a plugin 
initialization function that lets users modify global registry values; 
another approach is to provide callbacks that amount to the virtual 
functions in FrontendAction

-- 
Joshua Cranmer
News submodule owner
DXR coauthor




More information about the cfe-dev mailing list