Re: Progress on GCC plugins ?

[Andrew Haley <aph at redhat dot com>]

Ian Lance Taylor writes:
 > Andrew Haley <aph@redhat.com> 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