Thanks, Taras! I slightly updated this page, i.e. we would like to be able to load plugins through environment variables to be able to optimize programs transparently as it is done in MILEPOST GCC (without Makefile modifications). By the way, we plan to extend the Interactive Compilation Interface by the end of this year to access most of the internal transformations, however it will be based on the event and call-back mechanisms, which is similar to your GCC API proposal so we shouldn't have lots of compatibility problems if we later agree on the same plugin system...
Take care, Grigori > -----Original Message----- > From: Taras [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2008 11:57 PM > To: Basile STARYNKEVITCH > Cc: Brendon Costa; Hugh Leather; gcc@gcc.gnu.org; 'Sean Callanan'; Cupertino > Miranda; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek'; 'Diego Novillo'; Mike > O'Boyle; Grigori > Fursin > Subject: Re: Defining a common plugin machinery > > Basile STARYNKEVITCH wrote: > > <snip> > > My hypothesis is that several plugin mechanisms for GCC already exist > > (on some branches or somewhere else). If a small plugin patch has a > > better chance to get accepted into the trunk, we should limit > > ourselves to such a small thing. If big plugin machinery could be > > accepted (I would prefer that) we should understand what would make > > them more acceptable. In both cases, plugins have probably some > > requirements defined by the future runtime license, which I don't know > > yet. > http://gcc.gnu.org/wiki/GCC_PluginAPI > > I put up an API proposal. It's a result of the plugin API discussion at > the GCC summit. > > > Taras
