Hello All,
Grigori Fursin wrote:
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 am not sure of the relevance of the "new pass integration plugins"
examplified by MELT.
[on the other hand, I do know Grigori and I believe he thought quite a
lot about plugins, which I didn't. I only implemented one particular
plugin machinery = MELT, knowing well that my approach is quite peculiar
both in its goals and its implementation. I never thought of MELT as a
universal plugin machinery).
In my view, MELT fits quite precisely in the "production plugins"
definition, while indeed I expect it to be useful mostly for
"experimental/research" plugins.
In my view also, the "new pass integration plugin" category should not
really exist, because it probably can fit inside one (or both) of the
above categories.
MELT definitely claims to fit into the "production plugins" slot,
because MELT always was concerned by efficiency and most importantly
close integration of GCC internal structures. The major point of MELT
is its several idioms to fit into the *evolving* GCC internals API,
and I claim that the various MELT idioms (see my GROW paper) make
close integration into GCC internals possible, and perhaps even easy
(for each internal "feature" of GCC, it is really easy to code the
couple of MELT line to use it).
Of course, MELT is mostly motivated by "experimental/research plugins",
in the sense that MELT will be mostly useful for experimental and
prototyping. I never thought that MELT would be useful for coding
definitive optimisation passes, but it should be useful to at least
prototype them. Actually, I really believe that for ordinary
optimisation, any plugin machinery is not used. In other words, I tend
to think that even in -O3 (or a future -O4) no plugin will be dlopen-ed
by default in GCC. [by the way, I believe that this last fact is
unfortunate; I would like plugins to be routinely used inside GCC, but I
do know that most of the GCC community disagree.]
Also, I don't understand why "production plugins" or
"experimental/research plugins" could not be coded in another language
than C. For sure, they could probably be coded in a suitable subdialect
of C++ at least.
I do like Grigori's plugin API proposal. (but again, I definitely do not
claim to be a plugin theorist, only a particular plugin implementor,
with MELT having specific needs & solutions.).
I did not understood yet how exactly can Grigori's production plugin API
be used to add e.g. one plugin pass inside the pass manager. Eg how to
add one pass fooplugin_pass provided by a plugin just after the
pass_inline_parameters, or another plugin pass barplugin_pass just after
pass_ipa_struct_reorg?
I assume such things could be possible...
There is another issue which has not been discussed enough in my view.
The interaction between some GCC plugins and the GGC memory
manager/garbage collector. More precisely:
1. How can a plugin fooplugin.c use GTY() notation, and therefore
generate a gt-fooplugin.h which is #include-d at the end of fooplugin.c?
conceptually it could be quite easy: extend gengtype so that, in
addition to it peculiar current use [invocation from the Makefile
without program arguments] it is able to take two program arguments, the
input file -here fooplugin.c- and the output file -here gt-fooplugin.h
2. Even more important, how can a plugin register static or global GTY
roots and their marking routines (generated inside gt-fooplugin.h
above)? The point is that after a plugin has been loaded, the
ggc_collect routine should invoke some marking routines defined by the
plugin!
A simplistic very low level approach whould be to very simply extend
ggc_collect to take an additional marking routine & data. I did provide
a very small patch for that
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00431.html but very sadly
it has been rejected. Has it been accepted, one could easily e.g. add a
root registration in the plugin machinery and have all the dynamic roots
be marked with a very simple wrapper above the proposed
ggc_collect_extra_marking.
I still hope that some dynamic roots (and dynamic marking routines)
will be possible one day (otherwise, in my opinion, the whole plugin
effort would be doomed).
Regarding MELT, I believe that if a plugin facility has, in addition of
Gregori's feature, the ability to insert new dynamic passes and the
ability to add some extra GTY root & marking routine, I could fit MELT
into that. If that happens, MELT would become somehow a "metaplugin"
machinery, in the sense of a plugin which will itself load some dynamic
code.
In Grigori's table
Side-by-side comparison of production and research/experimental plugin
APIs
I believe that MELT probably don't need an extra column, and that for
the purpose, impact, implementation,aspects it fit into the first column
"production plugins" while for most other aspects MELT fits into the
second column.
Regards.
PS. In all this email, dynamic means simply obtained thru dlsym.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
