On Mon, May 30, 2011 at 11:18 PM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Mon, 30 May 2011 16:19:31 -0400 > Diego Novillo <dnovi...@google.com> wrote: > >> On Mon, May 30, 2011 at 13:44, Basile Starynkevitch >> <bas...@starynkevitch.net> wrote: >> >> > Diego and other people interested in plugins, what do you think of such >> > a proposal? >> >> I don't think that would work. Plugins need to know at what level >> they are working. FE plugins would have access to functions and data >> that gimple plugins would not. >> >> When a gimple plugin is working, it is likely that the front end will >> either not exist (e.g., we are in lto1) or its data destroyed, so we >> can't really support this. > > Of course, I never meant to really be able to register pragmas when > running such gimple LTO plugins. But as my discussion > http://gcc.gnu.org/ml/gcc/2011-05/msg00330.html suggested, we could > permit a plugin to be loadable both in cc1 & lto1 mode. Of course, when > doing LTO, it does not have access to the front-end information and > obviously cannot register pragmas (or other front-end things). But the > same plugin could be used in both modes (while currently, the plugin > cannot even be loaded). It is the plugin's responsibility (which should > be documented) to do appropriate things. > > An alternative could be that the short syntax > -fplugin=name > which for 4.6 means http://gcc.gnu.org/onlinedocs/gccint/Plugins.html > -fplugin=`gcc -print-file-name=plugin`/name.so > would really mean in the trunk & 4.7 > -fplugin=`gcc -print-file-name=plugin`/cc1/name.so > for cc1 and > -fplugin=`gcc -print-file-name=plugin`/lto1/name.so > for lto1 and so forth. > This would permit a plugin developer to make a plugin name so that > gcc -fplugin=name foo.c > and > gcc -fplugin=name -flto foo.c > both works. The burden is then on the plugin developer. > > Of course, in LTO, front-end information is lost, and plugin cannot > register any pragmas (because pragmas are front-end things). We (even > Pierre & me, we talked on phone before sending any emails to the list) > all knew that (because pragmas don't exist at Gimple level). > > But I still claim that having both > gcc -fplugin=name foo.c > and > gcc -fplugin=name -flto foo.c > work is a sensible goal. The naive users we have in mind for our > plugins should not even know (and probably don't even know) what cc1 & > lto1 are. They would be extremely surprised by the error given by gcc > in the last case: > lto1: error: cannot load plugin ..../name.so > > I strongly believe that we should tend to make plugins loadable both by > cc1 (& cc1plus) & by lto1. Of course, when loaded by lto1, the plugin > don't have access to front-end information (and the plugin developer > who knows by necessity the internals of gcc knows that). But it should > be loadable and behave appropriately. > > Of course the plugin I have in mind is MELT, but the discussion above > is absolutely not MELT specific. Imagine for instance a plugin coded in > C -e.g. an hypothetical improved plugin similar to graphite-opencl > http://www.gccsummit.org/2010/view_abstract.php?content_key=15 etc...- > which would use some external accelerators (think of OpenCL generating > plugins). Such plugins will probably want to add specific pragmas (e.g. > telling to generate OpenCL on a particular function or statement), and > these pragmas will be handled thru cc1. When the same plugin is loaded > by lto1, it would not register pragmas, but would still do the rest of > the job (in that hypothetical case, generate OpenCL kernel & Gimple > glue to invoke it). But that would be the same plugin. A naive user > don't think of a front-end or gimple plugin, it wants a plugin adding > some extra feature (for the naive user, the way that feature is > implemented, in front-end or in gimple, thru cc1 or lto1, is > irrelevant). > > So I still believe we should permit & encourage plugins which are > usable both with -flto & without it. Of course, they won't be able to > do front-end things from lto1, and plugin writers know that. But naive > plugin users should ignore such details. However, GCC should provide an > infrastructure permitting that.
Sure, I agree with all that. I totally disagree with the proposed method of implementation (I suggested two alternatives in the other reply). Richard.
