Andrew Haley <[EMAIL PROTECTED]> writes: > > We can make it as technically hard as possible, but it's way too late > > to make it technically hard. In fact, it's easy. You have to write > > some code to translate from tree to your proprietary IR, and then you > > have to plug that code into passes.c. > > Sure, but you then have to maintain your port forever, and there is a > substantial cost to this. I am pretty sure that if there were a > stable API to get trees out of GCC, people would have bolted gcc into > proprietary compilers. As there isn't a stable way to do it, it's > easier not to do it that way, and instead to contribute to gcc.
I agree that there is a cost to maintaining your port. I disagree that plugins make it any cheaper. See below. > > 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. > > 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. 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? 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. Ian