Re: Progress on GCC plugins ?

[Ian Lance Taylor <iant at google dot com>]

Andrew Haley <aph@redhat.com> 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