This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PLUGIN_PRAGMAS event
Diego Novillo wrote:
On Fri, Nov 6, 2009 at 11:18,>
>> I think the patch is OK. Richard, Diego, the impact is probably low,
>> OK during stage3?
If Rafael could apply the improved patch that is ok for me. Otherwise I can apply Rafael's improvement to the trunk (if
there is an ok, which I understood). I prefer Rafael to make the svn commit (because I am a bit scared of git generated
patches; I am not sure to understand how to apply them automatically, and I am afraid of making mistakes if applying
them manually.).
Richard Guenther
<richard.guenther@gmail.com> wrote:
If there is a current need for new hooks then it is ok to add them
during stage3. Current as opposed to theoretical.
Should I guess that the Google team have both a private branch of the trunk (with the added PLUGIN_* event) and a
private plugin using that new plugin event? Or is the branch public (perhaps the lto branch?)... I am very confused.
Otherwise, I am not sure to understand what is theoretical. I really need an explanation (remember that I am not a
native English speaker, so it is probably a human language issue - "theoritical" is translated into "thÃorique" in
Franch according to all my dictionnaries, but might have slightly different meanings in French and in English). I would
never bother calling any PLUGIN_* event a theoretical stuff (usually theory related to software is in greek letters and
typeset using the math mode of LaTeX, at least that is what I learned in France.).[Note *]
Why are some events more theoretical than others? What is the criteria for adding them or for rejecting them as theoretical?
I still believe that adding PLUGIN events which are rarely used in a invoke_plugin_callbacks (for example, which are
called only once like PLUGIN_PRAGMAS or are called a thousand times, not a million times) should be accepted easily now.
I believe that an explanation of how a not-yet-coded plugin could use them is enough. We can't expect people to code in
a week or two a useful plugin demonstrating the interest of an extra PLUGIN_* event. That would be a crazy expectation!
In particular, if the ICI guys want a few events invoked a few times, I believe these events should be accepted (even in
the current stage 3 of trunk = future 4.5). And they might want a few events inside the pass manager (but of course, I
don't understand their exact needs in details). I leave up to them to propose the PLUGIN_* event they need [but they
should propose them quickly]!
I hope that the PLUGIN_PRAGMAS will make into 4.5 and I hope that Diego (or some other good guys) would be able to push
CPP related PLUGIN_* events into 4.5.
Why cannot we accept any (I really mean any, not some) PLUGIN_* event provided that
1. its invoke_plugin_callbacks is not called very often [so does not impact performance of compilations without plugins]
2. it has a story - just a written description in English, not real code - which explains how it will be used in the
near future - ie before end of 2012?
3. it has a small patch with a few sentences of documentation in plugins.texi and a small testcase?
And I don't believe that the plugin API is carved in stone. It will evolve, and plugins won't be able to run both on
e.g. 4.5 & 4.6 without special care in their source code (this is not related to plugins. I believe that a pass written
in a dead branch merged with 4.4 or 4.3 cannot be merged without any changes into 4.5). It is really not an issue to add
several dozens of additional PLUGIN_* events [Note **]! And we could remove some of them later (in GCC 4.6 or 4.7 or
5.0) when we find out that they are not needed.
Regards.
Note [*]: An example of interesting theoretical stuff (written in North America by an American) is for example "Types
and Programming Languages" by Benjamin C. Pierce at http://www.cis.upenn.edu/~bcpierce/tapl/index.html - the theory is
typeset in LaTeX (mathematical formulas, greek letters, quantifiers... everything that GCC don't have - and has nothing
in common with plugins).
Note [**]: in particular, the numerical value of some PLUGIN_* event (that is, its position in the enum plugin_event of
gcc-plugin.h) is completely irrelevant, even for a minor 4.5.2 -> 4.5.3 change. We definitely should not expect a plugin
binary to run on a gcc different of the one for which it has been compiled (even for a minor release change). We might
want to write that more clearly! I would even wish that PLUGIN_PRAGMAS is written just after PLUGIN_ATTRIBUTES in the
enum plugin_event because it is conceptually near. Likewise, I believe that PLUGIN_START_UNIT should be just before
PLUGIN_FINISH_UNIT. The current order of PLUGIN_* events in the enum plugin_event is chronological and that is not pretty.
--
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 mines, sont seulement les miennes} ***