On Fri, 22 Apr 2011 14:15:11 +0000 (UTC)
Boris Kolpackov <bo...@codesynthesis.com> wrote:
> 
> I think fundamentally the requirements of those who use GCC as just a
> compiler and those who use it to do other things (via plugins) will be
> often at odds. The "compiler users" will always strive to keep as little
> syntactic information as possible to maximize performance. While the
> "plugin users" will want as much context as possible.

Yes. A general approach inside plugins would be to use a lot of
association tables (e.g. hash tables) to map existing GCC data to extra
(plugin) information. The MELT [meta-]plugin uses systematically this
approach, by providing hash tables keyed by every "ctype" (that is,
internal GCC GTY-ed data like gimple, edge, ...).

> A more general approach which could satisfy both camps would be to allow
> the "plugin users" to maintain the extra information if they need to. For
> example, I would be perfectly happy to build and use the typedef hierarchy
> outside of the AST. And all that I would need for this is a plugin event,
> similar to PLUGIN_FINISH_TYPE, that would give me base type, new type,
> and the decl nodes. 

I fully agree with that. My (biased) feeling is that there should be
much more plugin hooks, and that adding such hooks should be more easy
than it is currently. In my opinion, plugin hooks should be added,
especially those hooks which don't 

The current (sad) situation is a catch 22: extra plugin hooks are only
considered (by the GCC community) to be added only if there are real
plugins needing them, but plugins will be developped only if there are
enough relevant hooks to make them.

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 mine, sont seulement les miennes} ***

Reply via email to