plugin hooks

[Basile Starynkevitch]

Hello All,

I feel that the current plugin hooks, that is the set of plugin events
enumerated in the enum plugin_event of gcc/gcc-plugin.h and the
associated API in gcc/plugin.h (e.g. register_attribute) is perhaps
still incomplete.

My feeling is that adding plugin events (at least those for which
invoke_plugin_callbacks is not called a lot of times) is a negligible
addition that fits well in the current stage 3 of the trunk.
What do you think about that?

The point is that some plugins will need a lot more hooks, and that
waiting for 4.6 or 5.0 (i.e. the next release after 4.5 from current
trunk) will delay them possibly for at least a year. And adding these
additional hooks seems easy and reasonable now. And perhaps adding new
functions (I am thinking of register_plugin_builtin) to facilitate
plugin extensions.

I started adding a new wiki page http://gcc.gnu.org/wiki/plugin%20hooks 
to list the possible addition that should go into trunk

Comments are welcome.

Should I try to propose some patches to gcc-patches@ about that, or is
it impossible in the current stage3 of the trunk?

Regards.
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Richard Guenther-2]

On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
<basile@...> wrote:

> Hello All,
>
> I feel that the current plugin hooks, that is the set of plugin events
> enumerated in the enum plugin_event of gcc/gcc-plugin.h and the associated
> API in gcc/plugin.h (e.g. register_attribute) is perhaps still incomplete.
>
> My feeling is that adding plugin events (at least those for which
> invoke_plugin_callbacks is not called a lot of times) is a negligible
> addition that fits well in the current stage 3 of the trunk.
> What do you think about that?
>
> The point is that some plugins will need a lot more hooks, and that waiting
> for 4.6 or 5.0 (i.e. the next release after 4.5 from current trunk) will
> delay them possibly for at least a year. And adding these additional hooks
> seems easy and reasonable now. And perhaps adding new functions (I am
> thinking of register_plugin_builtin) to facilitate plugin extensions.
>
> I started adding a new wiki page http://gcc.gnu.org/wiki/plugin%20hooks to
> list the possible addition that should go into trunk
>
> Comments are welcome.
>
> Should I try to propose some patches to gcc-patches@ about that, or is it
> impossible in the current stage3 of the trunk?

Adding hooks just because you think they might be useful
isn't the way to go.

Richard.

[Basile Starynkevitch]

Richard Guenther wrote:
> On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
>
> Adding hooks just because you think they might be useful
> isn't the way to go.

Then what is the correct way to enhance the current plugin API. There
are a lot of stuff missing there.

I am not at all sure that all the experimental plugin work done so far
(in particular the ICI work inside MILEPOST and http://ctuning.org)
could fit into the existing plugin API.

So if you think that adding hooks which can be useful and are not costly
(you forgot that second part of my proposal) is the wrong way to work,
what do you propose?

Regards.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Ian Lance Taylor-3]

Basile STARYNKEVITCH <basile@...> writes:

> Richard Guenther wrote:
>> On Tue, Oct 27, 2009 at 1:15 PM, Basile STARYNKEVITCH
>>
>> Adding hooks just because you think they might be useful
>> isn't the way to go.
>
> Then what is the correct way to enhance the current plugin API. There
> are a lot of stuff missing there.
>
> I am not at all sure that all the experimental plugin work done so far
> (in particular the ICI work inside MILEPOST and http://ctuning.org)
> could fit into the existing plugin API.
>
> So if you think that adding hooks which can be useful and are not
> costly (you forgot that second part of my proposal) is the wrong way
> to work, what do you propose?

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 agree that it should be OK to add hooks in stage 3, if they are
clearly safe and clearly needed.

Ian

[Basile Starynkevitch]

Hello All,

>> Richard Guenther wrote:
>>> Adding hooks just because you think they might be useful
>>> isn't the way to go.


> Basile STARYNKEVITCH <basile@...> 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: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Ian Lance Taylor-3]

Basile STARYNKEVITCH <basile@...> writes:

> 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.

I didn't mean that the plugin had to exist, I meant that there had to
be a real plugin in view which needed them, not a purely theoretical
need.

> I have a concrete example here: plugin-specific pragmas (see
> PLUGIN_REGISTER_PRAGMA on http://gcc.gnu.org/wiki/plugin%20hook for
> details)

Sure, we clearly need some way for plugins to manage pragmas and
attributes.  This doesn't require much support.  I would first ask
whether attributes are enough, but it wouldn't bother me to have
support for pragmas.

> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?

Do this.

> 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 believe that such a patch is acceptable in stage 3.


On the other hand, skimming your list of hooks, I really question the
need for, e.g., REPLACE_PASS_MANAGER.  I would want to see a real use
case there before adding such a hook.

For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I
think it's an open question we should add a hook or whether the plugin
should just call cpp_define.  A hook means that we promise to always
have a way to do this in case cpp_define changes.  How do we decide
when to add that kind of thing to the plugin interface and when to
simply require the plugin to invoke gcc functions directly?

Ian

[Basile Starynkevitch]

Ian Lance Taylor wrote:
> Basile STARYNKEVITCH <basile@...> writes:
>
>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>
> Do this.

Will do probably tommorow or this evening!
>
> On the other hand, skimming your list of hooks, I really question the
> need for, e.g., REPLACE_PASS_MANAGER.  I would want to see a real use
> case there before adding such a hook.

 From several face to face discussions with ICI CTuning people (that it
Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
reply) I understood that GCC ICI is exactly doing that: it has replaced
GCC pass manager by its own, which invokes all the existing GCC passes
in some better order (or better number of invocation) and produces
better generated code (the tuning is done by machine learning
techniques; they did run their modified GCC a large number of times and
did build a database of measures.).

I cannot explain more in details what GCC ICI is actually doing. I hope
my ICI friends will answer here. Perhaps even Zbignew's latest patches
are related to the answer.

Regards.


--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Basile Starynkevitch]

Ian Lance Taylor wrote:
>
> For something like PLUGIN_ADD_CPP_MACROS, the need is clear, but I
> think it's an open question we should add a hook or whether the plugin
> should just call cpp_define.  A hook means that we promise to always
> have a way to do this in case cpp_define changes.  How do we decide
> when to add that kind of thing to the plugin interface and when to
> simply require the plugin to invoke gcc functions directly?

I (Basile) don't know much of libcpp. If a plugin can just call
cpp_define, this is ok for me. But then, we perhaps should document how
can that be called, and when (at plugin initialization, at
PLUGIN_START_UNIT? I don't know!)

I don't claim that a PLUGIN_ADD_CPP_MACROS is needed, I just think that
we should be able to declare additional builtin CPP macros [like
__DATE__ is, or perhaps like defined inside CPP is] from plugins.

I am not familiar enough with libcpp to understand if calling cpp_define
from a plugin is enough.

As a matter of fact, there are several *.def files which seems to be
#include-d to fill some constant arrays. For these kind of things, I
would suppose that perhaps some registration facility is needed,
probably as an addition register_plugin_XXXX function. Of course, not
every *.def fits into that scheme: I don't claim that plugin should
register a new kind of GIMPLE or TREE node (even if a file like
gcc/gimple.def or gcc/tree.def exists). [*] But the files
gcc/builtins.def & gcc/builtin-types.def seems to suggest a vector of
extra plugin-registered builtins & builtin-types and perhaps a
register_plugin_builtin function etc...

Regards.

(*) Half-joking note about adding GIMPLE node in plugins. Of course, if
all GCC was in C++, plugins could register extra GIMPLE nodes :-)
provided the GIMPLE node would be implemented as an abstract class (with
many virtual method slots).
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Richard Guenther-2]

On Tue, Oct 27, 2009 at 4:06 PM, Basile STARYNKEVITCH
<basile@...> wrote:

> Ian Lance Taylor wrote:
>>
>> Basile STARYNKEVITCH <basile@...> writes:
>>
>>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>>
>> Do this.
>
> Will do probably tommorow or this evening!
>>
>> On the other hand, skimming your list of hooks, I really question the
>> need for, e.g., REPLACE_PASS_MANAGER.  I would want to see a real use
>> case there before adding such a hook.
>
> From several face to face discussions with ICI CTuning people (that it
> Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
> reply) I understood that GCC ICI is exactly doing that: it has replaced GCC
> pass manager by its own, which invokes all the existing GCC passes in some
> better order (or better number of invocation) and produces better generated
> code (the tuning is done by machine learning techniques; they did run their
> modified GCC a large number of times and did build a database of measures.).
>
> I cannot explain more in details what GCC ICI is actually doing. I hope my
> ICI friends will answer here. Perhaps even Zbignew's latest patches are
> related to the answer.

The fix is not to add a hook to replace the pass manager but instead
to make the GCC pass manager more flexible itself.

Richard.

[Basile Starynkevitch]

Richard Guenther wrote:
>
> The fix is not to add a hook to replace the pass manager but instead
> to make the GCC pass manager more flexible itself.

I leave that task to my ICI friends (in CC). They have already an
implementation, and I believe they probably did propose some patches, or
are working on it.

However, it is not a small patch.

Also, I still believe that a hook for tha pass manager may make sense to
those brave souls wanting to experiment new pass managers in plugins,
etc. Having a hook for that is a way to encourage such crazy
experimentations.

Regards.

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Joseph S. Myers]

On Tue, 27 Oct 2009, Basile STARYNKEVITCH wrote:

> I (Basile) don't know much of libcpp. If a plugin can just call cpp_define,
> this is ok for me. But then, we perhaps should document how can that be
> called, and when (at plugin initialization, at PLUGIN_START_UNIT? I don't
> know!)

A plugin can call any non-static function in GCC, with the conditions for
its inputs and when it can be called being the same as for a direct call
from GCC; this is a consequence of the design to use -rdynamic.  These may
variously be documented in comments, the internals manual, list archives
and collective wisdom.  If you want better documentation for a particular
function, find where the existing documentation is (comments or internals
manual) and propose a patch.  If you think a static function should be
made non-static so plugins can call it, propose a patch with appropriate
rationale.

--
Joseph S. Myers
joseph@...

[Richard Guenther-2]

On Tue, Oct 27, 2009 at 4:48 PM, Basile STARYNKEVITCH
<basile@...> wrote:

> Richard Guenther wrote:
>>
>> The fix is not to add a hook to replace the pass manager but instead
>> to make the GCC pass manager more flexible itself.
>
> I leave that task to my ICI friends (in CC). They have already an
> implementation, and I believe they probably did propose some patches, or are
> working on it.
>
> However, it is not a small patch.
>
> Also, I still believe that a hook for tha pass manager may make sense to
> those brave souls wanting to experiment new pass managers in plugins, etc.
> Having a hook for that is a way to encourage such crazy experimentations.

The point is that compilation is not driven by the pass manager
but by a bunch of twisted code througout the compiler.  Better
fix that first before adding more twists.

Richard.

[Basile Starynkevitch]

Hello All

Basile STARYNKEVITCH wrote:
> Ian Lance Taylor wrote:
>> Basile STARYNKEVITCH <basile@...> writes:
>>
>>> * propose a simple patch to add the PLUGIN_REGISTER_PRAGMA event now?
>>
>> Do this.
>
> Will do probably tommorow or this evening!


I already did sent an initial proposal for the patch.
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01623.html

Regards.
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Rafael Espindola-2]

> 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 agree that it should be OK to add hooks in stage 3, if they are
> clearly safe and clearly needed.

Sorry for being late in joining the thread. I fully agree with this.
We should add hooks as someone finds a need for it.

Changes like this are likely to be safe, but I am not sure if they are
stage3 OK. We should probably look at it in a case by case basis.

> Ian
>

Cheers,
--
Rafael Ávila de Espíndola

[Rafael Espindola-2]

> 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 don't see a chicken and egg problem. Your work on making the GC
accessible to plugins is a good example why it is not :-)


> 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.

Sorry, the point is precisely that they should be concrete :-)

If you are actually coding a plugin and get to the stage "ok, now I
need a new hook", please send a patch adding the hook and a
description of what the plugin is trying to do.

Cheers,
--
Rafael Ávila de Espíndola

[Rafael Espindola-2]

> From several face to face discussions with ICI CTuning people (that it
> Grigori Fursin, Albert Cohen, Zbignew Chamski; all 3 are in CC of this
> reply) I understood that GCC ICI is exactly doing that: it has replaced GCC
> pass manager by its own, which invokes all the existing GCC passes in some
> better order (or better number of invocation) and produces better generated
> code (the tuning is done by machine learning techniques; they did run their
> modified GCC a large number of times and did build a database of measures.).
>
> I cannot explain more in details what GCC ICI is actually doing. I hope my
> ICI friends will answer here. Perhaps even Zbignew's latest patches are
> related to the answer.

We talked a bit in the summit about it. I think that the correct
solution is to make the gcc pass manager have the flexibility they
need so that their plugin can just call into the regular pass manager.

> Regards.
>
>
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: [phone]
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>

Cheers,
--
Rafael Ávila de Espíndola

[Basile Starynkevitch]

Hello All

Rafael Espindola wrote:
>> 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.
>

There are not so imaginary. I am sure I will need plugin specific
pragmas in 2010. I explained why. But I also told that it is more than
one man-year effort to exhibit a realistic plugin needing
PLUGIN_REGISTER_PRAGMA


>> 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 don't see a chicken and egg problem. Your work on making the GC
> accessible to plugins is a good example why it is not  :-)

Honestly, the [enormous in my view] effort I did make to push that GGC
related features into the trunk have been disproportionately important
w.r.t. the result. My work on GGC plugin events is precisely a good
example of why I need to anticipate my plugin needs.


> Sorry, the point is precisely that they should be concrete :-)
>
> If you are actually coding a plugin and get to the stage "ok, now I
> need a new hook", please send a patch adding the hook and a
> description of what the plugin is trying to do.


You are forgetting an important point in GCC.

The majority of GCC users won't compile GCC. Actually, I have concrete
experience that most GCC users are not even able (that is willing to
make the effort) to compile it. They will use a GCC in some distributed
*binary* form (e.g. the gcc-4.5 package of some future Ubuntu, Debian,
... distribution, released in mid 2010).

So in christmas 2010, a recently released Ubuntu contains the gcc-4.5
package (the compiler) and the gcc-dev-4.5 package (enough to compile a
gcc 4.5 plugin).

Now I (Basile) have developed a plugin by that time which will use a
PLUGIN_REGISTER_PRAGMA. If I requires its users to compile a gcc-trunk
(since only after mid 2010 will I be able to really demonstrate a valid
use of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single
person- will use my plugin. If my plugin runs on a standard 4.5 binary
distribution of gcc, I might have a few users!


I really think we should add more plugin hooks *now* for gcc-4.5. They
really cannot wait the future 4.6 release (in 2011, 2012?), especially
since the patches adding them are so short. And by definition, these
patches can't break anything [provided they don't hurt performance
measurably on compilation not using plugins, this is why I wrote about
plugin events whose invoke_plugin_callbacks is not called a million
times but only a few dozen times... or perhaps a few hundred times on a
big compilation. I mean that one additional invoke_plugin_callbacks at
each pass execution is probably acceptable]. So adding new events should
be done now. The PLUGIN_REGISTER_PRAGMA should not hurt performance of
GCC, since its invoke_plugin_callbacks is called once for a whole cc1
process!

And in a couple of years, indeed we might want to obsolete some plugin
events (like we do obsolete some other features of GCC). Only time can
tell which events are really useful.

Mind you, the buying point for plugins is to avoid asking users to
compile the entire GCC compiler but still have some extension ability.
Nobody likes to do that, except we GCC hackers, and Linux distribution
makers.

Sometimes I have the intuition that several GCC people are afraid of
plugins. I cannot understand why. When the Adobe Flash plugin crash in
my Mozilla, I don't curse the Mozilla team, but Adobe (and of course the
many sites using too much that proprietary technology). The main concern
of the GCC community should not be abuse of plugins, it should be the
survival of GCC in the long term.

I really think we should help as much as possible plugins to be a
success! And in my opinion, that means provide the necessary hooks in
4.5 [especially those for which the patch is tiny, like
PLUGIN_REGISTER_PRAGMA] not in the trunk in a couple of years. This
takes into account that GCC releases are quite a rare event (there is no
major GCC release every 3 months).


Regards


PS. Are we absolutely sure that GCC will still be dominant in the
compiler landscape five or ten years from now? I am not!

PPS. I think that most north-american GCC hackers grossly underestimate
the effort needed to push even a minor patch for e.g. european hackers.
There are lot of issues (English language, timezone, lack of near
collegues working on GCC and which I could meet in a few minutes, major
cultural differences, market differences [most processor makers are not
European]...) to consider

--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Richard Guenther-2]

On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH
<basile@...> wrote:

> Hello All
>
> Rafael Espindola wrote:
>>>
>>> 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.
>>
>
> There are not so imaginary. I am sure I will need plugin specific pragmas in
> 2010. I explained why. But I also told that it is more than one man-year
> effort to exhibit a realistic plugin needing PLUGIN_REGISTER_PRAGMA
>
>
>>> 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 don't see a chicken and egg problem. Your work on making the GC
>> accessible to plugins is a good example why it is not  :-)
>
> Honestly, the [enormous in my view] effort I did make to push that GGC
> related features into the trunk have been disproportionately important
> w.r.t. the result. My work on GGC plugin events is precisely a good example
> of why I need to anticipate my plugin needs.
>
>
>> Sorry, the point is precisely that they should be concrete :-)
>>
>> If you are actually coding a plugin and get to the stage "ok, now I
>> need a new hook", please send a patch adding the hook and a
>> description of what the plugin is trying to do.
>
>
> You are forgetting an important point in GCC.
>
> The majority of GCC users won't compile GCC. Actually, I have concrete
> experience that most GCC users are not even able (that is willing to make
> the effort) to compile it. They will use a GCC in some distributed *binary*
> form (e.g. the gcc-4.5 package of some future Ubuntu, Debian, ...
> distribution, released in mid 2010).
>
> So in christmas 2010, a recently released Ubuntu contains the gcc-4.5
> package (the compiler) and the gcc-dev-4.5 package (enough to compile a gcc
> 4.5 plugin).
>
> Now I (Basile) have developed a plugin by that time which will use a
> PLUGIN_REGISTER_PRAGMA. If I requires its users to compile a gcc-trunk
> (since only after mid 2010 will I be able to really demonstrate a valid use
> of PLUGIN_REGISTER_PRAGMA), nobody -I really think not a single person- will
> use my plugin. If my plugin runs on a standard 4.5 binary distribution of
> gcc, I might have a few users!
>
>
> I really think we should add more plugin hooks *now* for gcc-4.5. They
> really cannot wait the future 4.6 release (in 2011, 2012?), especially since

I don't agree at all.  Also I have the feeling that plugins will in
the end result
in less developers on the core GCC infrastructure and thus plugins are bad
for GCC.

Richard.

[Basile Starynkevitch]

Richard Guenther wrote:

> On Wed, Oct 28, 2009 at 8:34 PM, Basile STARYNKEVITCH
> <basile@...> wrote:
>>
>>
>> I really think we should add more plugin hooks *now* for gcc-4.5. They
>> really cannot wait the future 4.6 release (in 2011, 2012?), especially since
>
> I don't agree at all.  Also I have the feeling that plugins will in
> the end result
> in less developers on the core GCC infrastructure and thus plugins are bad
> for GCC.

I respectfully disagree with Richard, and have the following opinion.

Because of plugins ability, some *more* people will learn a bit the
internals of GCC (enough to code their plugin) and amongst them, a few
people will eventually -later- join the core GCC developers (e.g.
because they need a hook). So the effect of plugins on the size of the
GCC community should be a gradual increase, not a regression!

The point is that plugins will enable unexpected usage of GCC, and this
is positive (and will bring gradually more people inside the community).

Regards.


--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: [phone]
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

[Joern Rennecke-4]

Quoting Grigori Fursin <grigori.fursin@...>:
> Also, I hope that we will start collaborating with Joern Rennecke in  
>  a few weeks to update the ICI
> and GSOC'09
>
> developments based on the recent feedback to see if we can move it  
> to the mainline ...

We still need a branch name for that.  Since GCC is currently in phase 3,
I suppose we should plan on re-baselining at least once - re-baselining
from 4.6 experimental mainline after 4.5 is branched - so instead of
a gcc version number a branch date seems more suitable.

I.e. if the branch were to be created today, I propose to use the name
branches/ici-20091102-branch for the branch.