This is the mail archive of the gcc-patches@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: [plugins] [patch] Initial implementation of GCC plugin support


Hi all,

On Tue, Feb 24, 2009 at 3:12 AM, Grigori Fursin <grigori.fursin@inria.fr> wrote:
>
>
> By the way, I don't know if I missed that or we haven't discussed that -
> do we need an API revision number and provide a function to obtain this
> number within plugins or we associate it uniquely with the version of the
> compiler?..
>

Added this in the TODO list.

On Tue, Feb 24, 2009 at 5:50 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
>
> gcc -fplugin=whatever --version needs to output plugin version strings
> (probably calling cc1 with appropriate options to make it load plugins and
> output their versions).  Likewise --help, with plugin bug reporting
> addresses.

Added this in the TODO list.

On Tue, Feb 24, 2009 at 10:43 AM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
>
> So perhaps adding an explicit -fdisable-plugin-version-check flag which
> would turn the error message into a warning or a notice could make sense. I
> am not sure if the plugin should decide to accept slightly incompatible
> versions (ie if we should differentiate, it should not be the plugin author
> to decide...)  This is really a user decision.

Added this in the TODO list.

On Tue, Feb 24, 2009 at 11:05 AM, Taras Glek <tglek@mozilla.com> wrote:
>
> I think it will depend on the plugin as to how it wants to be inserted, some
> plugins don't care about registering passes, others just want to be notified
> when any passes run and others yet will want to register multiple passes,
> reorganize existing passes, etc. So it makes sense to let the plugin mess
> around as much as it needs with passes.
>
> My thoughts on solving this are:
> a) the pass manager should provide all of the pass
> enumeration/positioning/registration stuff. It does not make sense to
> duplicate parts of what the pass manager does in plugin.c. If the stuff does
> not seem to belong in passes.c, then it shouldn't be part of gcc.
> b) If we are going to have an incomplete or hacky api, it might as well live
> in the plugin.

Yes, I agree that the current implementation has its limitations.
However, I think it does provide a simple way for the plugin writers
to hook in new passes pretty easily. Yes, it doesn't allow reordering
or selectively-executing existing passes or any other drastic pass
manipulation, but I guess a lot (if not most) of plugins would only
require the ability to insert a new analysis or optimization pass. And
asking individual plugins to implement their own pass management seems
too much to me. I totally agree with you that we probably should come
up with a better way to integrate the existing pass
management/chaining code with the plugin support. I think this can be
implemented in later enhancements. I have added this item in the TODO
list.

I also understand your concerns on the maintainability of the plugin
pass management support (as any change to the existing pass management
could potentially break it). However, once the plugin support is in
the trunk with proper test cases in place, any changes made to the
pass management will need to make sure it doesn't break the plugin
support or the tests would fail.

On Tue, Feb 24, 2009 at 2:03 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
>
> Just make sure that the plugins are really initialized, and perhaps even get
> some initial event, when gcc is invoked without any source file.

As you also found out, running gcc or g++ without input source files
will not invoke cc1 or cc1plus, which means where we call
initialize_plugins() in cc1/cc1plus doesn't really matter in this
case. In order to support your usage (or '--version' and '--help'
options) with plugins (without input source files), we will need to
modify gcc/g++ drivers. I have noted this issue in the TODO.

I will submit the revised patch (with changes incorporating Diego's
review comments) to the branch after finishing my final bootstrapping
and testing to get the ball rolling.

Please also take a look at the TODO lists in
http://gcc.gnu.org/wiki/plugins and see if I miss (or misunderstand)
anything.

Thanks,

Le-chun


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