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. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
