Re: [plugins] Comparison of plugin mechanisms

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

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} ***