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: [Re: new plugin events]


On Sun, Nov 8, 2009 at 6:35 PM, Terrence Miller <terrencem@sbcglobal.net> wrote:
> < Forwarded due to missing address>
>
> -------- Original Message --------
> Subject: ? ? ? ?Re: new plugin events
> Date: ? Sun, 08 Nov 2009 18:25:21 +0100
> From: ? Basile STARYNKEVITCH <basile@starynkevitch.net>
> To: ? ? Terrence Miller <terrencem@sbcglobal.net>
> References: ? ? <4AE72A4F.8000303@starynkevitch.net>
> <4AF28075.7020808@starynkevitch.net> <4AF291A6.7000600@starynkevitch.net>
> <38a0d8450911050824l838fd92ya9f3a08205c80a85@mail.gmail.com>
> <4AF33453.7090200@starynkevitch.net>
> <38a0d8450911060724h3c6f9ddh3e84c2c763ac4de0@mail.gmail.com>
> <b798aad50911060800w5bffaf50tdabbbf2d78be4d22@mail.gmail.com>
> <84fc9c000911060818s3462aff1r1ebfb298506b6939@mail.gmail.com>
> <b798aad50911060827r1105ad3fna194ff5b898ce95@mail.gmail.com>
> <4AF4634D.5050303@starynkevitch.net>
> <b798aad50911061036g3be83df2n8d8ca5c4144c3c8d@mail.gmail.com>
> <4AF47257.8040307@starynkevitch.net> <4AF6FB88.4030303@sbcglobal.net>
>
>
>
> Terrence Miller wrote:
>>
>> I think this debate is missing one important issue. In order to generate a
>> patch to GCC
>> you have to know a lot more about the compiler internals than is required
>> to create
>> a plugin. ?I am doing some casual experimentation with compiler based
>> source browsing
>> and would love to have the DECL event(described below) added to the plugin
>> API.
>> I would prefer to not have to figure where that plugin should be called.
>>
>
> It is perhaps true for the DECL event you are talking about (which I did not
> understood fully), but I won't say that coding a plugin is *in general*
> easier than proposing a patch to core GCC.
>
> My perception is that most *middle* end plugins are working on Gimple and
> other middle-end representations. Usually, they do that by adding a pass in
> the pass machinery. And knowing what pass to add (or replace) is as
> difficult when coding a plugin than when coding a patch to GCC core.
>
> Conversely, I would suspect than many previous patches (which have now bee
> incorporated in GCC core) could have if a plugin machinery have been
> available at their time (which is false since plugin facilities is just
> coming in 4.5 which has not yet been released), first been developped as
> plugins -at least to experiment their viability & interest- and later one
> proposed as a patch.
>
> This is why I believe that plugins will probably -at least for middle-end
> processing- have also the role of GCC branches today, with a very important
> difference. Almost nobody compiles branches today (in the general GCC user
> community - I am not talking of the smaller GCC developper community), and
> it could be the case that some plugins will be used.
>
> For example, as far as I know, no common Linux distribution provides a
> package for any kind of GCC branch. I believe (perhaps I am too optimistic)
> that some Linux distributions will package some few GCC plugins.

You keep re-iterating this (IMHO bogus) argument.  I don't see how a plugin
in development is any different here - nobody will build or distribute it.
OTOH after a branch is mature it will be merged into the GCC core, so it
will be immediately available in distributed GCCs.

Richard.


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