Dear all, I noticed a long discussion about plugins for GCC. It seems that it's currently moving toward important legal issues, however, I wanted to backtrack and just mention that we at INRIA and in the MILEPOST project are clearly interested in having a proper plugin system in the mainline of GCC which will simplify our work on automatically tuning optimization heuristics (cost models, etc) or easily adding new transformations and modules for program analysis.
We currently have a simple plugin system within Interactive Compilation Interface (http://gcc-ici.sourceforge.net) that can load external DLL plugin (transparently through the environment variables to avoid changing project Makefiles or through command line), substitutes the original Pass Manager to be able to call any passes (new analysis passes for example) in any legal order and has an event mechanism to rise events in any place in GCC and pass data to the plugin (such as information about cost model dependencies) or return parameters (such as decisions about transformations for example). Since it's relatively simple, we are currently able to port it to the new versions of GCC without problems, however, naturally, we would like to have this functionality within the GCC mainline with the defined API (that what I discussed with Taras from Mozilla during GCC Summit this year). I believe it may help making GCC a modular compiler and simplify future designs (and can be in line with the idea to use C++ for GCC development if Ian moves this project forward). By the way, Hugh Leather also developed an interesting plugin system for GCC that allows to substitute internal GCC functions with the external ones within plugins to enable hooks inside GCC (he mentioned that he plans to release it soon)... Furthermore, we will then be able to use our current MILEPOST tools and Collective Compilation Framework to automatically tune default GCC optimization heuristic for performance, code size or power consumption (instead of using -O1,2,3 levels) for a particular architecture before new versions of GCC are actually released (or for additional testing of a compiler using different combinations and orders of passes). And when the compiler is released, users can further tune their particular programs interactively or automatically through the external tools and GCC plugins. By the way, we are extending current ICI for GCC 4.4 to add cost-model tuning for major optimizations (GRAPHITE, vectorization, inlining, scheduling, register allocation, unrolling, etc) and provide function cloning with different optimizations, and naturally would like to make it compatible with the potential future common GCC plugin system, so I hope we will be able to agree on a common plugin design soon and move it forward ;) ... Regards, Grigori ============================= Grigori Fursin, INRIA, France http://fursin.net/research > -----Original Message----- > From: Taras Glek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, September 16, 2008 11:43 PM > To: Diego Novillo > Cc: Basile STARYNKEVITCH; gcc@gcc.gnu.org; Sean Callanan; Albert Cohen; > [EMAIL PROTECTED] > Subject: Re: Defining a common plugin machinery > > Basile STARYNKEVITCH wrote: > > Hello Diego and all, > > > > Diego Novillo wrote: > >> > >> After the FSF gives final approval on the plugin feature, we will need > >> to coordinate towards one common plugin interface for GCC. I don't > >> think we should be adding two different and incompatible plugin > >> harnesses. > > > > What exactly did happen on the FSF side after the last GCC summit? I > > heard nothing more detailed than the Steeering Committee Q&A BOFS and > > the early draft of some legal licence involving plugins. What happened > > on the Steering Commitee or legal side since august 2008? Is there any > > annoucement regarding FSF approving plugins? > > > >> I am CCing everyone who I know is working on plugin features. > >> Apologies if I missed anyone. > >> > >> I would like to start by understanding what the plugin API should > >> have. What features do we want to support? What should we export? > >> What should be the user interface to incorporate plugin code? At > >> what point in the compilation stage should it kick in? > >> > >> Once we define a common API and then we can take the implementation > >> from the existing branches. Perhaps create a common branch? I would > >> also like to understand what the status and features of the > >> different branches is. > > > > > > The MELT plugin machinery is quite specific in its details, and I > > don't believe it can be used -in its current form- for other plugins. > > It really expects the plugin to be a MELT one. > > > > From what I remember of the plugin BOFS (but I may be wrong), an easy > > consensus seems to be that plugins should be loadable thru the command > > line (probably a -fplugin=foo meaning that some foo.so should be > > dlopen-ed), that they could take a single string as an argument (using > > -fplugin-arg=bar) and that plugins add essentially new passes into > > pass.c - I am happy with such a picture (and could fit MELT easily > > into it; in its current form MELT is adding a few basilys*passes into > > passes.c, each having a gate which try using a MELT closure somewhere > > so is equivalent of testing if the pass is enabled.). > > > > Albert Cohen & Grigori Fursin (both in CC) from INRIA have an > > "Interative Compiler Interface" (a big patch to GCC) which could be > > helpful to enhance this idea of extending the pass manager. AFAIK, > > they also have some plugin facility (or maybe I am wrong). Perhaps > > some ideas or code could be reused for plugins. > > > > I have no idea if some general plugin code evolved recently, i.e. if > > someone is actively working on it. > > > > If someone is coding on plugins, please tell the gcc@ list. > Hi Guys, > We are actively using and maintaining our plugin API at Mozilla. We > moderated the plugin discussion at the summit. From our discussion > sounds like we need to be able to hook into the middle-end(pass manager) > and the frontend. As far as I know nobody has needed anything of the > backend yet. > We are using the -fplugin syntax that Basile described above to dlopen > our plugins. As Basile mentioned, the pass manager API is extremely > important. Plugins need to be able to list passes(thus all passes need > unique names) and to insert a new pass at arbitrary positions. If I > recall correctly, Grigori's work also needs to be able to reorder > existing passes. > > Beyond that, there need to be general callbacks sprinkled throughout the > code. At the plugin BoF we decided that something like > plugin_callback(EVENT_NAME, void *data) would suit us well. Here > EVENT_NAME would be an enum describing the callback. Examples: > > * PLUGIN_FINISH_STRUCT(data would point at tree_node for the type > that gcc just finished building) > * PLUGIN_FINISH_GCC(before gcc exits) > * PLUGIN_CXX_CP_PRE_GENERICIZE (data is a function body tree_node) > for being able to look at fe gimple. > * PLUGIN_PLUGIN_SETUP for when it's time to register with the pass > manager > * other stuff such being notified before particular passes execute(I > think Grigori needs this). > > For my treehydra plugin it is important to land the GTY patch that Diego > reviewed. I can start submitting patches for review whenever someone is > ready to review them. Our plugin code isn't yet structured exactly as > described but I will happily restructure the API to something acceptable > and submit stuff for review. > > See http://developer.mozilla.org/en/Dehydra for more details on > Mozilla's plugin work. > > Cheers, > Taras
