GCC unplugged

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).