This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: using plugin and lto: problem linking c-pragma symbol
On Mon, May 30, 2011 at 11:18 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Mon, 30 May 2011 16:19:31 -0400
> Diego Novillo <dnovillo@google.com> wrote:
>
>> On Mon, May 30, 2011 at 13:44, Basile Starynkevitch
>> <basile@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.