Grigori Fursin wrote:
Dear all,
Zbigniew and I prepared a page on GCC Wiki comparing several current plugin
mechanisms (some parts should be updated) with some suggestions to move forward:
http://gcc.gnu.org/wiki/GCC_PluginComparison
In case we mixed up or misunderstood something about other plugin
efforts, update this page, please ...
Basically, we currently see 3 complementary categories of GCC plugins, depending
on the nature of the extension: production, experimentation/research, and new pass
integration. Each category naturally calls for slightly different API features.
I respectfully disagree. I think this division is unnatural. Most
plugins will be extending GCC with new features and there is a
possibility of those plugin eventually becoming part of the GCC core. I
don't see any difference between our "production" plugins, experimental
plugins and new pass plugins. There are use-cases where our "production"
plugins would want to rearrange pass execution and even to add new passes.
I think something like the pass manager APIs you suggest should go into
tree-pass.h. It doesn't make sense to put every new API that plugins
would want to use into plugin headers as eventually some GCC code is
likely to benefit from the same features.
I don't know enough about feature stuff, but it seems like that'd be
something that should also be a separate API from plugins.
I don't know enough about the intent of the event stuff, but it sounds
like that might actually be something only plugins would care about.
Considering that there are already communities behind "production" and
"experimental" plugins,
we think that it would be better to merge two. We will try to prepare a small patch to support
"experimental" plugins by the beginning of next week. In the mean time, would like to know your
thoughts on that matter and how should we proceed forward !..
Like I said, I don't think the communities are as distinct as you are
implying.
Cheers,
Taras
