plugin hooks for plugin-provided builtins?

Diego Novillo dnovillo@google.com
Wed Sep 15 03:26:00 GMT 2010


On Tue, Sep 14, 2010 at 15:22, Basile Starynkevitch
<basile@starynkevitch.net> wrote:

> I'm just trying to figure out what are the features in 4.6 which will
> be useful to my work. I know that in a couple of weeks, they are frozen
> (since 4.6 is ending stage 1). The gengtype patch series

No.  End of October.

> http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01029.html I am trying to
> push with Jeremie Salvucci is also almost needed for MELT (and for any
> plugin using GTY). I have no idea if it will make into 4.6, because I
> still don't understand which *reviewer* is interested by them.

If you are trying to install a patch, that makes *you* the interested
party.  Laurynas has been making great review work for the patches
you've posted so far.  Although I have not reviewed the patches, I
have not heard anything against them.

Incidentally, this is an issue I would like to address.  We need
someone interested in maintaining the GC machinery.  Any volunteers?
Laurynas?

> I really do not understand the philosophy of: work hard for one or two
> years making a plugin, and the GCC community will perhaps eventually
> consider -and only after the work is completed- adding the tiny hook
> which would have saved you 6 months of work. [I am speaking of course
> of small hooks which can be incorporated into the trunk by a single
> small patch and which have no measurable effect on GCC performance when
> not used]

You are blowing things out of proportion.  You also belong to this
community, so do not make it an us-vs-them problem.

You started the thread with a hypothetical use case scenario.  We
clearly we don't want to add these hooks just because they may be
useful.

It is true that you are perhaps the biggest user of plugins at a time
where everything related to internal APIs is in a state of flux.  So,
you can imagine what the external APIs look like.  You *must* expect
challenges here.

This work that you are doing, must it be based on plugins for a
fundamental reason?

Given your interest in plugins, why not do the following:

1- Do your work in a branch, adding all the hooks and facilities that
you think are needed.
2- Develop the plugin against that branch and solve the API issue in
that branch.
3- Keep the rest of the community in the loop.  In particular, I am
interested in having a working plugin facility.  But I *know* that we
cannot get to that without solving our API issues.

Want to work with me on that?


Diego.



More information about the Gcc mailing list