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