I originally wrote this email as a reply to Ian Lance Taylor on a different list, and he suggested that I send it also to the gcc list. Please cc me on replies, since I'm not subscribed to the list. I hope I'm not being too off-topic or off-the-mark.
Let me write down some reflections on gcc extensibility, even if I'm not familiar at all with gcc internals. 1. I imagine the plugin API ought to stay in plain C, right? 2. Then there are at least two ways to think about the plugin API to, e.g., the gcc tree abstraction. Either one can define a C API one think the plugins will like, and then implement that on top of the internal C++ interfaces. These will be small wrapper functions, which lets the internal interfaces evolve without affecting the plugins. Or one sticks to a single "unified" tree API, to be used *both* internally and by plugins. I suspect the second option is the right one, because it brings some equality between plugin authors and gcc developers. It should make it easier to adopt a plugin into gcc proper. Together with (1), this forces the internal interface to be C rather than C++, which I guess you may see as a serious disadvantage. Going for a unified API, one gets less independence between plugins and gcc internals, but in return, one gets less clutter, and I think it may improve quality. Otherwise, it seems likely that one ends up with an internal interface which is powerful but somewhat ugly (internal use only, right?) and an external interface which may be beautiful on the surface, but in practice it's a second class citizen and awkward for doing interesting things with. 3. What is the purpose of the plugin API? I can see that it should make it easier to prototype new optimization passes. Both for educational purposes, and research, as well as by the gcc developers themselves. One of the goals you stated was "I think parts of GCC needs to move toward being a component of tools other than pure compilation, such as refactoring, profile analysis, debugging." I think we can all agree that's highly desirable. To be more concrete, I think it would be useful have access to information from the parse tree, from the symbol table (both for compiler and linker), dataflow analysis, etc, when editing C code in emacs. Is a plugin API the right tool for that type of integration? Or should one also have a gcc library, and have various other specialized tools link to that library? Maybe the organization of valgrind could provide some inspiration, with a couple of different tools on top of the same machinery. Happy hacking, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
