This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new plugin events


On Fri, Nov 6, 2009 at 8:28 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Diego Novillo wrote:
>>
>> On Fri, Nov 6, 2009 at 14:00, Basile STARYNKEVITCH
>> <basile@starynkevitch.net> wrote:
>>
>>> I really insist that the position "events are only accepted if there
>>> exist a
>>> mature & running plugin needing them" is not sustainable.
>>
>> No. ?We are not communicating here. ?The relative maturity of the
>> plugin that needs it is not relevant. ?Just that there is some plugin
>> that could take advantage of it.
>>
>> If ICI and/or MELT and/or Dehydra and/or whatever other plugin people
>> are developing need new plugin events, then by all means lets add
>> them!
>
>
> Then I believe that me Basile & Diego have the same position, while Richard
> Guenther did express an incompatibly different position in the past (or
> perhaps I Basile misunderstood what he Richard meant by theory).

No, read what Diego said (emphasis mine): "Just that there _is_ some
plugin that could take advantage of it."

As opposed to "There _might_ be some plugin that could take advantage
of it."

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.

If we don't have at least plugin API stability we could throw plugins
down the toilet.

I especially want to avoid adding plugin callbacks in code that is
known to be not the way it should be.  Instead GCC internals should
be cleaned up and adjusted to be plugin-friendly.  This probably
will apply to some of the pass-manager hooks people are going to
propose.

> So I understood that people could propose new plugin events, provided that
> they are not too costly to implement (mostly meaning that the
> invoke_register_plugins calling them does not slow down compilations not
> using plugins), and provided people can explain clearly why they need it. It
> is not necessary to have a useful plugin coded & runnable to show the need
> of the event.

Yes it is.  And I am going to voice this opinion whenever I see people
are adding hooks because it is fun to do so.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]