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