Defining a common plugin machinery

[Basile STARYNKEVITCH]

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 .gch must match or be compatible with those used
> when using the .gch, so in essence the above is already forbidden by the
> fact that adding or removing -fplugin= would render the .gch unusable. 
> I seem to recall that the .gch file records the entire set of options
> used when it was built and gcc refuses to consider the file if it does
> not exactly match, however the documentation seems to imply that only
> certain options are automatically checked/rejected while others are the
> responsibility of the user to enforce:
> <http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html>.

In my opinion we should, in the first version of plugin code inside 
trunk, disable pre-compiled headers when using any plugin. Notice that 
PCH require specific support by GGC (probably in gcc/ggc-common.c), 
hence additional processing for plugins, more than what I mentioned in 
http://gcc.gnu.org/ml/gcc/2008-09/msg00342.html

Only when plugins are actually usable, and when we get real practical 
experience on them, should we tackle PCH. We should not bother before.

And my understanding was that PCH are essentially an experimental, not 
very satisfactory (but definitely useful to users) features. I even 
thought that some people are interested in working on a way to replace 
it by something neater (IIRC, this was informally discussed at the 2008 
GCC summit, I forgot by whom..).



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). So far, I have (in MELT branch) a very 
unsatisfactory bad solution. I defined a few passes, which may (or not) 
be enabled by some plugins. What I would dream is some machinery to be 
able to have the plugin ask 'insert my pass foo_pass after the last pass 
which construct the IPA SSA tuple representation' and this is not 
achievable today.

 From what I understand, the ICI http://gcc-ici.sourceforge.net/ effort 
is tackling with related issues.


Actually, I believe that passes should *much* more described, and I mean:

   * each pass should be documented, by a paragraph like the beginning 
comment of alias.c cse.c df-core.c dse.c gcse.c ipa-cp.c ipa-inline.c 
ipa-type-escape.c omp-low.c tree-cfg.c tree-inline.c tree-mudflap.c or 
tree-nrv.c or tree-optimize.c ... I was suggesting in 
http://gcc.gnu.org/ml/gcc/2008-09/msg00177.html that each pass *should* 
have such a description (less than a hundred english words each), and 
even dreaming of some simplistic comment marking convention (perhaps 
texinfo markup inside a comment) and some simple (e.g. awk) script to 
extract these documentary comments from source code and merge them into 
a generated pass-internal-doc.texi file. The issue here is not technical 
[writing such an awk script is simple] but social [have each pass 
developer document a little his/her pass in some 'standard' format]. And 
such a crude device (script merging comments) would help to have more 
documentation.

   * each pass should have a unique name. Note that I submitted a patch 
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00057.html which has been 
accepted & committed to the trunk (on august 1st 2008) which permit 
passes to be named without having any dump. A possible minor issue is 
probably that several test suites (I have no idea which ones) depend on 
the pass name. This is much more a social issue (have each pass 
developer be concerned of naming his pass uniquely) than a technical one 
(giving a unique name to every passes is realistically possible only to 
the elite people understanding nearly all of GCC. They are very few, and 
they don't need any documentation anymore). Each pass developer should, 
without major effort, be able to document in one paragraph his pass and 
uniquely name it. In contrast, having a single (or a few) person doing 
all this work is not realistic.

   * each major internal GCC representation should be more or less 
documented (this is probably the case today: Tuples, generic trees, RTL 
have a documentation, even if is imperfect), and each pass should tell 
what representation it changes, it invalidates, it destroys, it provides 
(some but not all of this is already available in struct opt_pass thru 
flags, eg properties_required, todo_flags_start, ...).

I believe that a major (more social than technical) issue about plugins 
(assuming almost all of them are implementing some kind of passes) is:

   * where should this plugin be inserted (after which pass, before 
which pass)
   * what kind of representations this plugin consumes, provides, 
enhances, invalidates, requires, needs, ...

Actually, I believe that each pass need to be much more described, both 
in formal ways (e.g. extending the struct opt_pass) and in some 
semi-structured comments & documentation. (A related, but much more 
futuristic, ideal would be some more declarative pass manager). This 
will be very important for plugins (which are necessarily code less 
tested, etc..).
What will happen when several plugins are used?
At which point should a given plugin put its own pass?

This last question is bothering me. Currently in MELT I am inserting 
passes thru a trial & error fashion - this is sad.

Don't forget that plugins will enable code written by people which 
understand less all the internals of GCC than top-level GCC contributors.

And I believe that plugin will be widely used, in particular for many 
non-code generation tasks (like Dehydra or MELT).

Regards.
-- 
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} ***