Re: new plugin events

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Nov 6, 2009 at 10:41 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Richard Guenther wrote:
>>
>> No, read what Diego said (emphasis mine): "Just that there _is_ some
>> plugin that could take advantage of it."
>>
>
> Diego also said "could", not "can" (emphasis mine). I understood that the
> plugin is not supposed to be mature. It could even be in its design phase...
>
>> As opposed to "There _might_ be some plugin that could take advantage
>> of it."
>
> The intermediate phrase is "There _will_ be some plugin...". I am mostly
> thinking of the brave guys wanting to make a plugin for GCC, and missing
> some particular event.
>
>>
>> I want to avoid the situation where we prematurely add a plugin hook
>> and later recognize it should have been different in a sublte way once
>> the first user appears. ?Thus, I want to avoid 1) changing existing
>> plugin callbacks, 2) removing existing plugin callbacks, or even worst
>> 3) changing its semantics. ?This all applies to between major and
>> even more so minor GCC releases.
>
> I agree with the list to avoid, but it is really premature today for 4.5. It
> will be a concern for 4.6 or 5.0!! And it probably won't be that much a
> concern. I would imagine that removing useless plugin events in 4.6 or 5.0
> would be possible...

What?  Removing useless plugin events?  How can a plugin event be
useless if you added it with the premise that it might have a valid good use?!
But I guess you agree with me here - you do _not_ know if the events
you want to add are useful!

>> If we don't have at least plugin API stability we could throw plugins
>> down the toilet.
>
> Could you define plugin API stability? For me it is premature to think of
> it.
> First, the Plugin API is so new that it cannot be stable for 4.5. It could
> be stable if it existed before 4.5 which it didn't.
>
> Now, if you think of stability of a given plugin -call it foo here, that is
> a foo1.c foo2.c foo.h compiled into foo.so and passed to gcc-4.5
> -fplugin=foo.so- betweem eg 4.5 & 4.6 do you mean that
>
> 1. ? the binary foo.so will work for both gcc-4.5 & gcc-4.6 ?
> I strongly believe that is impossible, and should not be dreamed of.

Of course not.

> 2. ? the binary foo.so will work for both gcc-4.5.1 & gcc-4.5.2 ?
> I tend to believe that is not necessary. People (or more probably Linux
> distribution makers) will recompile foo for 4.5.2. Plugins are free
> software, so users have the plugin sources (and distribution makers would
> recompile them).

Likewise.

> 3. ?the sources foo*.[ch] can be recompiled without patches between gcc-4.5
> & gcc-4.6?

I expect so in most of the cases.  Well, with 1 and 2 it is already hard
to argue plugins are useful - look at the set of headers you need to install
to build a plugin!  It is as easy to just build a patched GCC.

What I expect will happen is:

People using multiple plugins will have multiple versions of GCC installed,
as the plugin developers are very likely not providing plugin sources for
all available GCC versions around in the wild - like vendor compilers
that are often far away from the branch they are packaged from.  Thus,
to these people plugins will be as useful^H^H^Hless as patches to GCC.

I can see that some very popular plugins be built and distributed alongside
vendor compilers.  But then it would be as much work for the vendors
to integrate GCC patches, which they of course do today!  Instead of
plugins being a clear advantage here they slow down GCC (because
its internal symbols are to be exported), they reduce the value of
the FSF GCC version because it lacks features only available as plugin.

So - I think the whole plugin story is somewhat poorly constructed.  Not
without 1 and 2 being part of the reason for this.  Adding another
churn to this, 4. the plugin api and hooks will change willy-nilly as we like,
isn't going to make that story any better.

Over-exaggerating as always on this topic, but I think I found the
shed I like to paint.  At least you can count me to the non-believers here.

To add something positive at the end - I do see plugin as a useful way
to integrate something into GCC that the GCC developer community
does not like to see integrated.  Like the static analysis plugins available
today, or ICI as available today.  But I do believe that both of them
do have a place inside GCC itself if they are well designed and integrated
within GCC!  Here often GCC and its grown architectural limitations
make it difficult to provide a convincing integration - a chance to fix
GCC!  Which unfortunately plugins will hinder rather than foster.

Thanks for still listening,
Richard.