Hello All,
Richard Guenther wrote:
Adding hooks just because you think they might be useful
isn't the way to go.
Basile STARYNKEVITCH <bas...@starynkevitch.net> writes:
Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.
Ian Lance Taylor wrote:
We should add hooks as we find plugins that need them. Simply adding
a laundry list of hooks that we think might be needed will most likely
cause us to overdesign. We know that we can write interesting plugins
today, so we're not missing anything critical.
I believe there is a strong chicken & egg issue here. Ian is suggesting
that hooks should be added only when an existing plugin would need them,
but I believe that on the contrary plugins won't appear if they don't
have a sufficient set of hooks. People won't even bother to make plugins
if they feel the set of hooks is blantly unsufficient. [They will either
experiment on their own GCC branch, or avoid GCC entirely, for instance
using LLVM instead]. But working on one's branch is much more painful
than coding a plugin!
I agree that it should be OK to add hooks in stage 3, if they are
clearly safe and clearly needed.
I have a concrete example here: plugin-specific pragmas (see
PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for
details)
I have two imaginary use cases here.
First, some sophisticated static analysers [like Frama-C on
http://frama-c.com which is LGPL licence and happens to be developped by
collegues] extend the C syntax to add some code annotations to
declarations and to blocks and perhaps to C statements. The GCC
equivalent would be to have attributes (for annotation of declarations)
and pragmas (for annotation of blocks), because there is no way from
Gimple to parse a comment near a declaration or a block. So if someone
wanted to plug such kind of analyzer into GCC thru a plugin, he would
need additional pragmas, just because the current GCC archtecture does
not permit any kind of "language extension" from plugins. As another
case, remember the old lint from the 1980s. It did parse comments like
/* NOTREACHED */ and the equivalent functionality in GCC can only be
provided by builtin-s (like our builtin_unreachable today) or by
pragmas. If we want a superlint-like GCC plugin, we need such hooks like
plugin specific pragmas & builtins.
Second, some optimisation pass which would perhaps detect some loops to
be eligible for running on a GPU thru OpenCL and which would clone some
simple functions into a stub calling OpenCL code and generate that
OpenCL code -that is source to source transformation of some C or gimple
into OpenCL- for some external OpenCL compiler [no free OpenCL
implementation seems to exist today; if you know about one, tell me
please!]. I have not the details in mind, because I did not work yet on
that subject. But this is not a week of work, but probably two years of work
[I probably will work on such a GPLv3 plugin using my MELT technology in
2010-2011, with funding from OpenGPU french project. I already feel that
2 years is not enough for that goal.]
Both use cases above are very ambitious, and I definitely cannot make a
plugin prototype in a week or two (or even in two months of work) to
show that a PLUGIN_REGISTER_PRAGMA is useful. But I am able to propose a
patch for PLUGIN_REGISTER_PRAGMA in a day or two of work.
So what do you (Ian, Richard and other) suggest:
* not bothering at all, and do all experience inside MELT branch only
* propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
I definitely am not able to propose a usable realistic plugin prototype
for that PLUGIN_REGISTER_PRAGMA patch now, but I am able to propose a
patch (and perhaps a testcase that is a plugin which invokes the
system(3) function; of course such a plugin is extremely unsafe and
useless, but fellow, it is the simplest example I can think of) now.
I also tend to believe that the discussion above applies to the
PLUGIN_ADD_CPP_MACROS proposed in http://gcc.gnu.org/wiki/plugin%20hooks
but I do admit that it is more tricky to implement (it means adding
plugins inside libcpp).
I am waiting for a concrete reply to my following question:
should I propose a patch for registering pragmas for (and from inside) a
plugin, given the motivations discussed above? Is that acceptable in the
current stage3 state of the trunk?
I forgot to say that I believe plugins are a wonderful feature of GCC
4.5 (and perhaps the condition of its success). I also believe that, if
the plugin machinery is well designed (so provide enough hooks) it will
be used by a lot of plugins, and so plugins will appear which will be
everything but the kitchen sink, and that is a very good thing. We
should not be afraid of plugin providing unexpected uses to GCC. We
hould be afraid of lack of plugins (because eg the API is incomplete)!
Another plugin use case is frontend for exotic languages (like Mercury,
Erlang, Pascal, ...). But this requires a lot more hooks.
And I don't think at all that plugins will open GCC to proprietary
software invasion. GCC is too complex a beast for that!
Regards.
--
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} ***
