On Fri, Mar 16, 2012 at 6:19 PM, David Malcolm <dmalc...@redhat.com> wrote:
> It seems that GCC has provided an API for registering plugins, but no
> API for the plugins to then actually use... Perhaps the C++ move would
> be alleviated by having an actually C API for plugins to use? I started
> writing a possible API for plugins, the idea being to port my python
> plugin to this as a middle layer, but it strikes me that this could also
> be used for the embedding case as well. So perhaps the first step might
> be to implement the plugin API, and that could evolve into the
> inter-library API that the different parts of a more modular GCC could
> use to talk to each other?
>
> The proposed API might look like this:
>
> /*
> Pure C for maximum compatibility
> All macros begin with a "GCC_" prefix
> All symbols begin with a "gcc_" prefix with _ separators, though I
> happen to prefer the CPython style (e.g. "GccBasicBlock_GetIndex");
> bikeshed away!
> (You may only call such a symbol when you have the Big GCC Lock?)
> All types begin with a "gcc_" prefix (again, I'd prefer CPython style
> e.g. "struct GccBasicBlock").
> How acceptable is it to autogenerate parts of the API? (this is what
> I do in my python plugin; naturally I use python for this).
> */
>
> /* Compatibility macros: */
> #define GCC_API(RETURN_TYPE) extern RETURN_TYPE
>
> /* All types are opaque; internally these might simply embed one of
> gcc's real types as its single field; integration with GC could be
> interesting though: */
> typedef struct gcc_cfg gcc_cfg;
> typedef struct gcc_basic_block gcc_basic_block;
> typedef struct gcc_edge gcc_edge;
>
> /* Declarations: control flow graphs */
>
> /* gcc_cfg: */
> GCC_API(gcc_basic_block *)
> gcc_cfg_get_entry(gcc_cfg *cfg);
>
> GCC_API(gcc_basic_block *)
> gcc_cfg_get_exit(gcc_cfg *cfg);
>
> /* gcc_basic_block: */
> GCC_API(int)
> gcc_basic_block_get_index(const gcc_basic_block *bb);
>
> /* gcc_edge: */
> GCC_API(gcc_basic_block *)
> gcc_edge_get_src(gcc_edge *e);
>
> GCC_API(gcc_basic_block *)
> gcc_edge_get_dest(gcc_edge *e);
>
> /* ...etc... */
>
Yes, I think we desperately need something like the above. And I was
strongly against our current "plugin API" because of all the reasons
you cite. But it seems that the people driving plugins meant that plugins
should be able to do everything an embedded GCC pass can do.
I think an API like you propose with clear direction towards
1) providing simple and forward-compatible ways of, first of all
_introspection_ (to make static analyses possible)
2) and _instrumentation_ (to make dynamic analyses possible)
and not for implementing everything that GCC can (that will be never
forward/backward compatible). The above should eventually be
possible on the different IL kinds GCC has, but first and foremost
targeting plain GIMPLE (+ SSA) plus the CFG and the CGRAPH
parts should be enough.
Providing python/guile/whatever bindings for such simple(!) C plugin API
should then eventually embedded into GCC itself.
But no, I'm not volunteering (I'm volunteering to do the review work).
The above has the same issue as the "we-want-to-be-more-like-LLVM"
stuff - it lacks the people to actually implement it, and GCC at its
present state still has to evolve, we can't and do not want to just spend
a complete release or two with just turning GCC upside-down.
Richard.
