Hello everybody,
2009/2/13 Basile STARYNKEVITCH wrote
>Hello All,
>
>I am not sure of the relevance of the "new pass integration plugins"
> examplified by MELT.
>[...]
>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.
>[...]
>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.
The classification of plugins into the three categories was intended
to illustrate the differences in API constraints; MELT is an example
of multi-language programming that calls for non-C bindings in the
plugin API. This is in fact orthogonal to the level of abstraction,
which is the key differentiator between the "production" and the
"experimentation" approaches. Efficiency is a concern in all cases,
but is addressed at different levels: the idea behind the experimental
part of the API is to help searching for a good/better way of dealing
with a problem, while the production API should provide the means of
implementing the chosen method as efficiently as possible.
> 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...
To support "dynamic" passes (supplied by plugin), Grigori's API needs
two more primitives to register and unregister new passes (plus a
function to get the struct opt_pass by name for the production API).
The rest of the machinery remains unchanged. The solution will be
then to:
* register the dynamic passes upon loading the plugin,
* generate an event in execute_pass_list (say, "select_next_pass"),
* modify pass chaining (or run passes directly) in the corresponding
callback, based on the current position in the pass list,
* unregister dynamic passes when unloading the plugin.
>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.
Insertion of dynamic passes can be implemented very rapidly (cf.
above). For GTY, maybe your patch came just too early - the
motivation for it is much stronger now. Finally, the "meta-plugins"
seem a natural consequence of the plugin concept itself and I expect
to see more of them as soon as the plugin mechanism gains momentum in
the community.
All the best,
Zbigniew
