Ian Lance Taylor writes: > Andrew Haley <[EMAIL PROTECTED]> writes: > > > > If gcc supports plugins, then all we've eliminated is the need to > > > plug that code into passes.c. But that is the easiest part of the > > > job. Adding plugins is not going to require us to support a stable > > > tree interface or anything along those lines; if it did, I would > > > oppose that. > > > > Ahhhhhh. I don't know about that: once we have a plugin > > infrastructure, we have to document it and there will be pressure to > > stabilize it. I don't believe that an unstable plugin architecture > > has any viability at all. > > I disagree. In fact, if creating a plugin architecture comes with a > requirement to make a stable structure for trees, then I'm opposed to > it. That would hurt us far more than it would help. This is not a > slippery slope. > > An unstable plugin architecture is still very useful for our users. > Correct installation of a patched gcc is an awkward affair that many > people get wrong. Correct installation of a plugin requires no more > than a command line option. Plugins make it easy for people to share > their gcc extensions across projects or across university departments.
Even if the interafce changes continuously? Maybe. I find it hard to believe, but we'll just have to agree to differ. > > > So this seems to me to be a very weak argument against plugins. > > > Adding plugins does not make it noticeably easier to integrate gcc's > > > frontend with a proprietary compiler. And adding plugins would not > > > change the issue of whether such a combination violated the GPL. > > > > > > Do you disagree with this assessment? > > > > I think there is a real possibility that, had we had such a plugin > > interface years ago, some of the gcc back-ends and optimization work > > we have would never have been paid for by some companies, and so gcc > > would be a worse compiler. > > Most new gcc back-ends are private, so I don't buy that part of the > argument. And in any case nobody is talking about plug-ins for gcc > backends. We're talking about plugins at the tree/GIMPLE level. Yeah, I know. I'm thinking about proprietary compilers (not just back-ends, optimization passes) bolted on to a gcc front-end to get Linux compatibility. > And, frankly, very few people are paying for general new gcc > optimizations. As far as I know, the only people doing so are > companies like IBM and Red Hat, and they would contribute their > changes anyhow. Do you have any examples in mind? ISTR that at least part of if-conversion was paid for, but I can't remember how much of what I know is confidential and how much is just plain wrong. > When I was in the business of convincing people to pay for gcc > work, I had a laundry list of general gcc improvements to sell. I > was never able to get a dime except for target specific > improvements. A plugin architecture would not make any difference > to that kind of work. No, but it might mean that entire gcc ports go away, as people who already have in-house compilers use them with a gcc front-end for Linux ports, rather than funding gcc ports. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
