On Sun, Nov 8, 2009 at 6:35 PM, Terrence Miller <terren...@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 <bas...@starynkevitch.net> > To: Terrence Miller <terren...@sbcglobal.net> > References: <4ae72a4f.8000...@starynkevitch.net> > <4af28075.7020...@starynkevitch.net> <4af291a6.7000...@starynkevitch.net> > <38a0d8450911050824l838fd92ya9f3a08205c80...@mail.gmail.com> > <4af33453.7090...@starynkevitch.net> > <38a0d8450911060724h3c6f9ddh3e84c2c763ac4...@mail.gmail.com> > <b798aad50911060800w5bffaf50tdabbbf2d78be4...@mail.gmail.com> > <84fc9c000911060818s3462aff1r1ebfb298506b6...@mail.gmail.com> > <b798aad50911060827r1105ad3fna194ff5b898c...@mail.gmail.com> > <4af4634d.5050...@starynkevitch.net> > <b798aad50911061036g3be83df2n8d8ca5c4144c3...@mail.gmail.com> > <4af47257.8040...@starynkevitch.net> <4af6fb88.4030...@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.
