Dave Korn
Cc: 'Taras Glek'; 'Grigori Fursin'; 'Hugh Leather'; 'Basile
STARYNKEVITCH'; gcc@gcc.gnu.org;
'Sean Callanan'; 'Cupertino Miranda'; [EMAIL PROTECTED];
[EMAIL PROTECTED]; 'Taras Glek';
'Diego Novillo';
ri Fursin'; 'Hugh Leather'; 'Basile
STARYNKEVITCH'; gcc@gcc.gnu.org;
'Sean Callanan'; 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
; 'Taras Glek';
'Diego Novillo'; 'Mike O'Boyle'
Subject: Re: Defining a common
Hello All,
(I'm replying to Grigori & CC to gcc@ - I suppose every person
interested in plugins is reading the gcc@ list)
Grigori Fursin wrote:
http://gcc-ici.sourceforge.net/papers/mfpp2007.pdf
Thanks for the reference.
By the way, if I am correct, GCC MELT (developed by Basile)
also at
7;; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> 'Taras Glek';
> 'Diego Novillo'; 'Mike O'Boyle'
> Subject: Re: Defining a common plugin machinery
>
>
> > Sounds like you're almost in need of a generic data marshalling interface
> > here
Aye up,
I like the idea of signals. The chaining code can be automatically
generated by FFI - the code to do it is pretty trivial.
Also, if instead of having a single struct with all the signals in,
you could have a hashtable of signals referenced by a string id, then
plugins could defi
> Sounds like you're almost in need of a generic data marshalling interface
> here.
>
Why do we need the complication of data marshaling?
I don't see why we need to define that all plugin hooks have the same
function interface as currently proposed. I.e. a single void*. This
makes a lot of w
On Thu, Oct 09, 2008 at 06:02:40PM +0200, Grigori Fursin wrote:
> Well, I see the point and I am fine with that. And as I mentioned I can
> continue
> using some patches for my projects that currently use environment variables
> or later
> move to the GCC wrappers if the majority decides not to
Taras Glek wrote on 09 October 2008 17:37:
> Grigori Fursin wrote:
>> Well, we need to return values or even structures using plugins for our
>> MILEPOST project
>> to tune cost models. A simple example is loop unrolling: in our current
>> plugin implementation (MILEPOST GCC/ICI) we register a pl
Grigori Fursin wrote:
Well, we need to return values or even structures using plugins for our
MILEPOST project
to tune cost models. A simple example is loop unrolling: in our current plugin
implementation
(MILEPOST GCC/ICI) we register a plugin function that will predict loop unrolling and pass
TARYNKEVITCH'; gcc@gcc.gnu.org;
> 'Sean Callanan';
> 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek';
> 'Diego Novillo'; 'Mike
> O'Boyle'
> Subject: Re: Defining a common plugin machinery
>
&
ursin'; 'Diego Novillo'; 'Hugh Leather'
> Cc: 'Brendon Costa'; 'Taras Glek'; 'Basile STARYNKEVITCH'; gcc@gcc.gnu.org;
> 'Sean Callanan';
> 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek
Hugh Leather wrote:
Aye up all,
I think the env var solution is easier for people to use and
immediately understand. There would be nothing to stop those people
who don't like env vars from using the shell wrapper approach. Why
not allow both?
I think the other replies addressed this que
Grigori Fursin wrote on 09 October 2008 17:03:
> Well, I see the point and I am fine with that. And as I mentioned I can
> continue using some patches for my projects that currently use
> environment variables or later move to the GCC wrappers if the majority
> decides not to support this mode ;)
g;
> 'Sean Callanan'; 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> 'Taras Glek'; 'Mike
> O'Boyle'
> Subject: RE: Defining a common plugin machinery
>
> Diego Novillo wrote on 09 October 2008 14:27:
>
> > On Thu,
Diego Novillo wrote on 09 October 2008 14:27:
> On Thu, Oct 9, 2008 at 05:26, Hugh Leather <[EMAIL PROTECTED]> wrote:
>
>> I think the env var solution is easier for people to use and
>> immediately understand. There would be nothing to stop those people who
>> don't like env vars from using t
On Thu, Oct 9, 2008 at 05:26, Hugh Leather <[EMAIL PROTECTED]> wrote:
> I think the env var solution is easier for people to use and immediately
> understand. There would be nothing to stop those people who don't like env
> vars from using the shell wrapper approach. Why not allow both?
Envir
Aye up all,
I think the env var solution is easier for people to use and
immediately understand. There would be nothing to stop those people who
don't like env vars from using the shell wrapper approach. Why not
allow both?
Are you sure about this style of event/callback mechanism?
> > Personally I'm against the env var idea as it would make it harder to
> > figure out what's going on. I think someone mentioned that the same
> > effect could be achieved using spec files.
> >
> Ian mentioned the idea of creating small wrapper scripts with the names:
> gcc/g++ etc which just ca
9 AM
> To: Grigori Fursin
> Cc: 'Basile STARYNKEVITCH'; 'Brendon Costa'; 'Hugh Leather'; gcc@gcc.gnu.org;
> 'Sean Callanan';
> 'Cupertino Miranda'; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Taras Glek';
> 'Diego Novillo'
> Personally I'm against the env var idea as it would make it harder to
> figure out what's going on. I think someone mentioned that the same
> effect could be achieved using spec files.
>
Ian mentioned the idea of creating small wrapper scripts with the names:
gcc/g++ etc which just call the re
Grigori Fursin wrote:
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 Interacti
AIL PROTECTED]; 'Taras Glek'; 'Diego Novillo'; Mike
> O'Boyle; Grigori
> Fursin
> Subject: Re: Defining a common plugin machinery
>
> Basile STARYNKEVITCH wrote:
> >
> > My hypothesis is that several plugin mechanisms for GCC already exist
> >
Joseph S. Myers wrote:
On Mon, 6 Oct 2008, Taras wrote:
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.
I believe the API also needs interfaces for verifying compatibility
(exporting the required GCC vers
On Mon, 6 Oct 2008, Taras wrote:
> 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.
I believe the API also needs interfaces for verifying compatibility
(exporting the required GCC version, target triplet and any
Basile STARYNKEVITCH wrote:
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
Hello All,
Robert Dewar wrote:
Gerald Pfeifer wrote:
On Wed, 1 Oct 2008, Basile STARYNKEVITCH wrote:
is the goal to only permit FSF copyrighted GPLed plugins
The FSF is concerned about making and keeping software free.
Copyright assignment to the FSF is required to get code into the FSF
v
Gerald Pfeifer wrote:
On Wed, 1 Oct 2008, Basile STARYNKEVITCH wrote:
is the goal to only permit FSF copyrighted GPLed plugins
The FSF is concerned about making and keeping software free. Copyright
assignment to the FSF is required to get code into the FSF version of
GCC; it is not needed o
On Wed, 1 Oct 2008, Basile STARYNKEVITCH wrote:
> is the goal to only permit FSF copyrighted GPLed plugins
The FSF is concerned about making and keeping software free. Copyright
assignment to the FSF is required to get code into the FSF version of
GCC; it is not needed otherwise.
Gerald
Hi Brendon,
Thanks for reading all this :-) Comments in line.
Brendon Costa wrote:
I have notes inline below, following is my summary of libplugin from
what i understand of your posts:
* It exists as a fraemwork that works with GCC now
* It uses xml files to define plugins (Allows making ne
Brendon Costa wrote:
I believe we should first focus (when the runtime license will permit
that) on making whatever plugin machinery available and merged into
the trunk (when it comes back to stage one). This is not an easy task.
Isn't the point of this discussion to decide what features to put
> I believe we should first focus (when the runtime license will permit
> that) on making whatever plugin machinery available and merged into
> the trunk (when it comes back to stage one). This is not an easy task.
Isn't the point of this discussion to decide what features to put into a
plugin fra
Hello All,
Brendon Costa wrote:
Some questions:
* How does the framework interact with the compile command line arguments?
* Does this work on platforms that dont support -rdynamic or can it be
modified to do so in the future?
[I'm skipping the rest of an interesting post]
I thought that for
I have notes inline below, following is my summary of libplugin from
what i understand of your posts:
* It exists as a fraemwork that works with GCC now
* It uses xml files to define plugins (Allows making new plugins as
combinations of others without making a new shared library, i.e. just
create a
Hugh Leather wrote:
Aye up Basile,
Thanks for wading through my gibberish :-)
*Differences with other proposals.*
I'll have a stab at some differences between this system and the
others. But, this is going to be a bit difficult since I haven't seen
them all :-)
*Separating Plugin s
Aye up Basile,
Thanks for wading through my gibberish :-)
*Differences with other proposals.*
I'll have a stab at some differences between this system and the
others. But, this is going to be a bit difficult since I haven't seen
them all :-)
*Separating Plugin system from appliction
On Wed, Oct 01, 2008 at 06:03:21PM +0200, Basile STARYNKEVITCH wrote:
> So we now have many plugin proposals & experiments. However, we do know
> that there are some legal/political/license issues on these points (with
> the GCC community rightly wanting as hard as possible to avoid
> proprietar
Hugh Leather wrote:
Aye up all,
I've now been reading through some of the list archive. Some of the
posts were about how to tell GCC which plugins to load. I thought I'd
tell you how libplugin does it.
Thanks for the nice explanation. I'm not sure to understand exactly how
libplugin deal
uld like to make it
compatible with the potential future common GCC plugin system, so I
hope we will be able to agree on a common plugin design soon and
move it forward ;) ...
Regards,
Grigori
=====
Grigori Fursin, INRIA, France
http://fursin.net/research
---
Grigori Fursin, INRIA, France
http://fursin.net/research
-Original Message-----
From: Taras Glek [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 16, 2008 11:43 PM
To: Diego Novillo
Cc: Basile STARYNKEVITCH; gcc@gcc.gnu.org; Sean Callanan; Albert Cohen;
[EMAIL PROTECTED]
Subject: Re: Defi
k [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, September 16, 2008 11:43 PM
> To: Diego Novillo
> Cc: Basile STARYNKEVITCH; gcc@gcc.gnu.org; Sean Callanan; Albert Cohen;
> [EMAIL PROTECTED]
> Subject: Re: Defining a common plugin machinery
>
> Basile STARYNKEVITCH wrote:
> >
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:
>
>> Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
>>
>>> I am much more worried about passes and plugins (and I am very
>>> surprised to be almost the only one mentioning passes in plugin
>>> discu
Chris Lattner wrote:
Is the plugin machinery intended to eventually allow new (GPL
compatible) backends to be used? It would be nice to make llvm-gcc be a
plugin.
From what I remember of the plugin BOFS & the Steering Committee Q&A
sessions at last GCC summit permitting GPL-ed plugins is
On Sep 19, 2008, at 3:25 PM, Ian Lance Taylor wrote:
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
I am much more worried about passes and plugins (and I am very
surprised to be almost the only one mentioning passes in plugin
discussions). I feel it is a major issue (not a matter of coding
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> I am much more worried about passes and plugins (and I am very
> surprised to be almost the only one mentioning passes in plugin
> discussions). I feel it is a major issue (not a matter of coding, much
> more a matter of convention & understanding
On Fri, Sep 19, 2008 at 13:16, Basile STARYNKEVITCH
<[EMAIL PROTECTED]> wrote:
> I would be delighted if that would be easily possible, but I remember having
> asked at some LTO related session or meeting if LTO can be extended to add
> some additional data, and the answer was "we don't want to do
Brendon Costa wrote:
* Automatically loaded plugins as well as explicit user requested plugins
I would like to propose that we allow automatic loading of certain
plugins in addition to the explicit request for loading of plugins using
the -fplugin= command line option.
I think we agree that au
Taras wrote:
However, I do think it's awesome to be able to store plugin results in
the resulting binary to do LTO-style analyses. How well is that working
for you?
I would be delighted if that would be easily possible, but I remember
having asked at some LTO related session or meeting if LTO
Brendon Costa wrote:
Joseph S. Myers wrote:
I think this is a bad idea on grounds of predictability.
I can understand this view and was initially reluctant to suggest the
auto-load feature for this same reason. However i can not see another
solution that can be used instead of this to
On Fri, 19 Sep 2008, Brendon Costa wrote:
> 1) Dont allow additional search paths for plugins
I think we do want to allow the user to specify such a path on the
compiler command line, in addition to searching the standard libsubdir or
libexecsubdir location.
> 3) Somehow embed something in all
Brian Dessent wrote:
Basile STARYNKEVITCH wrote:
I'm not sure that pre-compiled headers (pch) should even work with
plugins. The reasonable solution is to disable them when any plugin is
used [...]
There's already an existing requirement that the compiler options used
when precompiling the .
Basile STARYNKEVITCH wrote:
> (a meta question: do we need to reply-to all, or should the gcc@ list be
> enough to discuss plugins, and the only destination of this interesting
> discussion?).
Reply-to-all is the common standard on the list. If you don't want a
personal copy then set the "Reply-
Brian Dessent <[EMAIL PROTECTED]> writes:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and callbacks?
Yes, that is pretty far fetched. Simply writ
Hello All,
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Brendon Costa wrote:
Basile STARYNKEVITCH wrote:
But what about the trunk, which uses tuples?
I know nothing about the t
On Fri, Sep 19, 2008 at 15:30, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and ca
Ralf Wildenhues wrote:
> > * Windows (cygwin/mingw)
> > As i understand the issue (I am not very familiar with this) you can't
> > have unresolved references in a plugin back to the GCC executable. I.e.
> > Building GCC with -rdynamic will not work on this platform. Do we move
> > most of the GCC
* Brendon Costa wrote on Fri, Sep 19, 2008 at 02:42:19AM CEST:
> What platforms do we want to support? I can think of the following
> categories:
> * Windows (cygwin/mingw)
> As i understand the issue (I am not very familiar with this) you can't
> have unresolved references in a plugin back to the
Basile STARYNKEVITCH wrote:
> But what about the trunk, which uses tuples?
I know nothing about the tuples and the trunk and whether tuples might
affect the way plugins work. Maybe others can comment...
To be honest i was more worried about how plugins will work with the
garbage collector and pre-
Ian Lance Taylor wrote:
> Write a one-line shell script to use as your compiler (that's what I
> would do), or define an environment variable which tells gcc which
> plugins to load (e.g., GCC_PLUGINS=/a/file:/another/file).
>
>
Thanks for the input.
The one-liner shell script is a very good op
Brendon Costa <[EMAIL PROTECTED]> writes:
> I have control over my project: foo, however i do not have control over
> project blah. The problem is with badly defined build system that do NOT
> allow a user to pass flags they want to to the compiler. This will
> likely result in having to edit the
Brendon Costa wrote:
Hi all,
Firstly, do others think it would be helpful to summarise any of this
information on a wiki page, or will these emails be fine?
Yes, updating the wiki is always nice. Don't forget to put reference to
the mails on gcc@ using their archive URL, please!
In this ema
Joseph S. Myers wrote:
> I think this is a bad idea on grounds of predictability.
I can understand this view and was initially reluctant to suggest the
auto-load feature for this same reason. However i can not see another
solution that can be used instead of this to achieve simple usability
for a
On Fri, 19 Sep 2008, Brendon Costa wrote:
> * Automatically loaded plugins as well as explicit user requested plugins
> I would like to propose that we allow automatic loading of certain
> plugins in addition to the explicit request for loading of plugins using
> the -fplugin= command line option.
Hi all,
Firstly, do others think it would be helpful to summarise any of this
information on a wiki page, or will these emails be fine?
In this email I will give my opinion on the questions asked by Deigo and
ask a few additional questions that may be relevant.
--
Wha
Hi all,
Diego Novillo wrote:
>
> After the FSF gives final approval on the plugin feature, we will need
> to coordinate towards one common plugin interface for GCC. I don't
> think we should be adding two different and incompatible plugin harnesses.
>
> I am CCing everyone who I know is working
Basile STARYNKEVITCH wrote:
Hello Diego and all,
Diego Novillo wrote:
After the FSF gives final approval on the plugin feature, we will need
to coordinate towards one common plugin interface for GCC. I don't
think we should be adding two different and incompatible plugin
harnesses.
What e
65 matches
Mail list logo
