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
