GCC unplugged

"Where does such flexibility make sense for compilers?"

I respectfully submit that you're not thinking outside the box enough.  An example I know of
that would benefit from a pluggable GCC is GCC-XML (http://www.gccxml.org), which has the
(limited, last I looked) capability of exposing part of the GCC internal representation as
XML.  No, I'm not an XML fanboy, but the wide array of XML tools that can be applied make code
transformations a great deal more **accessible to the average developer**.  I understand the
GCC-XML team had very deliberate push-back from the core GCC devs on integrating their work
precisely because of the "easing proprietary extensions" specter.  As a result, GCC-XML is
indeed a largely duplicate download of plain GCC.

This is just one example, though.  Perhaps you'd want to make better integration with a
debugger, farm out pieces to a co-processor, generate some fancy-schmancy metrics and graphs
for the suits... and on and on.  I don't think either of us can imagine all the possibilities.

All this notwitstanding, sure, an internal cleanup and better documentation would go a long
way towards attracting development energy.  It is, no doubt, "a staggeringly sensible idea,"
but other efforts to make GCC development accessible more approachable are pretty far along
the sensibility curve in my book, too.

The passes system would actually make it, hm, `more possible' to add plugins. It's just that
not every significant transform that affects properties of the IR is reflected in properties
visible to the passes system, and it would be really easy for a plugin author to screw up the
data flowing through the translation pipeline in subtle ways.

At the very least a pipeline author should (just as the author of any other GCC change) run
the testsuite after changing anything significant. And that takes hours, much longer than
recompiling the compiler itself, especially if you avoid building/testing libjava. If you're
doing that, yo may as well build the compiler too, negating the advantage of plugins.

Plus, a lot of things are still implemented by means of target-specific macros rather than
function pointers; those are not used so much in the front- and middle-end code, but that
doesn't mean they're not used at all. (This is a good ideal state to aim for, though its speed
impact if everything was so translated might be substantial. Some of those macros are called a
*lot*. We probably need memory-efficient IPA before this is practical, so we can turn them
into functions and then inline them across translation units, although even that would fail if
they had to be replaceable at runtime... right now compiling GCC with --combine runs every
machine I have access to out of memory, so that's not ready for prime time yet. Mind you my
largest box has only 1.5Gb of RAM and some of that is used for other things.)


GCCXML is the largest plus point of all this, really. I've often wanted to be able to suck
data out of GCC's IR, because GCC has already done a lot of analysis of the source for me, and
I'd rather not reproduce all that work when writing little source code auditing and
invariant-checking tools. RMS's concerns about proprietary consumers of that data are
increasingly irrelevant, IMNSHO: there are lots of proprietary systems which do similar things
already, and anyone wanting to use GCC to do it and with the skill to know what they're asking
for has the skill to add an export-bits-of-IR feature to GCC --- which they are of course
allowed to do, under the GPL. So this is really security-by-obscurity on RMS's part, which
depends on the insides of GCC remaining too obscure to easily modify: and obscure and
hard-to-modify internals are exactly what the GCC maintainers *don't* want (or at least I hope
they don't).