On Tue, Apr 3, 2012 at 12:03 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, Apr 2, 2012 at 7:21 PM, David Malcolm <dmalc...@redhat.com> wrote: >> I wrote a script and ported my proposed API for GCC plugins from my >> CamelCase naming convention to an underscore_based_convention (and >> manually fixed up things in a few places also). >> >> The result compiles and passes the full test suite for the Python >> plugin; that said, I'm still breaking the encapsulation in quite a few >> places (hey, this is an experimental prototype). >> >> You can see the latest version of it within the "proposed-plugin-api" >> branch of the Python plugin here: >> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=shortlog;h=refs/heads/proposed-plugin-api >> >> within the "proposed-plugin-api" subdirectory. > > Hmm, how do I get it? I did > > git clone http://git.fedorahosted.org/git/proposed-plugin-api > > but there is nothing in gcc-python-plugin/. And > > git checkout proposed-plugin-api > > says I'm already there ...?
Meanwhile the directory magically appeared (heh ...). Overall it looks good - but it seems to leak GCC headers into the plugin API (via gcc-plugin.h and input.h inclusion). Thus, it lacks separating the plugin API headers from the plugin API implementation headers? Or maybe I'm not looking at the right place. I also dislike the use of GCC_PUBLIC_API, etc. - everything in the plugin API headers should be obviously public - and the implementation detail should be an implementation detail that should not need to care. >> If this landed e.g. in GCC 4.8, would this be usable by other plugins? For sure. I'd say get the copyright stuff sorted out and start pushing things into the main GCC repository - where the obvious starting point is to get the makefile, configure and install parts correct. I'd concentrate on providing enough API for introspection, like simple things, counting basic-blocks, counting calls, etc. I'm not sure we want to expose gcc_gimple_walk_tree or gcc_gimple_print (or the gcc_printers for a start) - the latter would something that the python plugin would provide, resorting to introspecting the stmt itself. I also wonder about gcc_gimple_phi_upcast - why would you specialize PHI nodes but not any others? I'd have exposed gcc_gimple_code. In general the plugin API should provide exactly one (and the most flexible) way to do a thing (thus, not have gcc_gimple_assign_single_p) and the high-level consumers like the python plugin should provide nice-to-use interfaces. Thanks, Richard. >> Hope this is helpful >> Dave >>
