<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Oct 14, 2011, at 5:31 PM, Joshua Cranmer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div bgcolor="#FFFFFF" text="#000000">
This is a document in partial response to Douglas Gregor's recent
comment about needing someone to push forward a plugin proposal for
clang.<br>
<br>
What kinds of use cases would people have for a compiler plugin?<br>
<ul>
<li>Add a static analyzer<br>
</li>
<li>Production of ancillary metadata for types and declarations
(e.g., adding reflective capabilities to C/C++)<br>
</li>
<li>Custom optimization passes</li>
</ul>
The current architecture appears to assume that clang plugins and
clang itself are primarily useful for static analysis and not for
production. If I wish to use a plugin, I have to use:<br>
clang -cc1 -load /path/to/plugin.so -plugin Foo -plugin-arg-Foo Bar<br>
<br>
But if I'm trying to drop in this plugin in a regular build, I need
to do:<br>
clang -Xclang -load -Xclang /path/to/plugin.so -Xclang -add-plugin
-Xclang Foo -Xclang -plugin-arg-Foo -Xclang Bar<br>
<br>
By comparison, a gcc plugin lets me do:<br>
gcc -fplugin=/path/to/plugin.so -fplugin-arg-plugin-bar=baz<br>
<br>
The key things that gcc lets me do in a plugin that I think are
necessary for clang are to be able to define custom attributes and
pragmas, which are largely necessary for custom static analysis
scripts: for example, Mozilla defines several attributes to allow
checking of properties in their gcc plugins (e.g., enforcing
outparameter guidelines). All of its other features appear to be
either an artifact of its code design (e.g., GC interactions) or
features that are already supported (e.g., adding a new optimization
pass).<br></div></blockquote><div><br></div>Yes, I think it would be wonderful if plugins can define custom attributes/pragmas.</div><div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
Another thing which I think is necessary is a macro for the version
of clang being built, so that plugins can support multiple versions
of clang at the compiler level (supporting multiple versions in
binary form is inadvisable, I think).<br></div></blockquote><div><br></div><div>This seems fine, although with the amount of churn in Clang's ASTs, I doubt that any non-trivial plugin will be able to work with two released versions of Clang.</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
With that background, here is my rough proposal for plugins; there
are other changes that I think many plugin writers might like to
see, but I'll hold off on them, since they don't inhibit writing
useful plugins:<br>
1. Add in -fplugin= and -fplugin-arg-<plugin> options for the
compiler driver. All of the plugins in the library would be loaded
and run as if specified with -add-plugin (in other words, clang
still compiles the code).<br></div></blockquote><div><br></div><div>Sure, this makes sense. At this point, it also makes sense to make sure that multiple plugins get chained together properly. For example, plugins are added in the order they are specified on the command line, and any implicitly-created consumers (e.g., the ASTConsumer for generating IR) go at the end of this list. </div><div><br></div><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
2. Add examples of plugins that illustrate iterating over the AST
and getting IR for functions for futher passes.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>One useful example would be to add an "annotate" attribute to various declarations, and verify that the attribute made it through to the IR.</div><div><br></div><div>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?</div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
3. Ensure existence of support in clang for custom attributes.<br></div></blockquote><div><br></div><div>This is its own side-topic. At the moment, the "annotate" attribute is the only generally customizable attribute. </div><br><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">
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.<br></div></blockquote></div><div><br></div>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.<div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></div></body></html>