Re: Progress on GCC plugins ?

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

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

> > 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.
> 
> Well first of all, that code becomes GPL so the IR isn't truely "proprietary".

I'm with you on that.  The fact remains, people have done this
already.  Whether the result is legally proprietary or not is almost
irrelevant; as you said earlier, the FSF is unlikely to actually sue.


> > 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?
> 
> No, not in that case, but I don't see that as the only case.  Another
> case would be somebody who wanted to keep an optimizer proprietary by
> making it a plug-in.  My view is that because of the linkage with the
> GCC IR, it can't be proprietary in that case, but that's the harder argument
> to make legally.

I can not deny the possibility of somebody writing an (effectively)
proprietary optimization pass.  However, I consider that to be both
unlikely and irrelevant.  People can always make private changes to
gcc.  We care about proprietary changes if they start distributing
them.  But that is an unlikely scenario.  There is no money to be made
in compiler optimization.

If we make it clear that we consider any plugin to be covered by the
GPL, then any attempt to sell a proprietary optimization will face
community opposition, thus making even less business sense.

And in the end, what will they have?  A marginal improvement over the
standard compiler.  Since they can not hide the results, we can figure
out what they are doing and recreate it.  In fact, it will be easier
for us to do so than it would be for a private port.

So I think this is a groundless fear.  When considering hypothetical
consequences, we need to consider both their likelihood and their
benefit or cost.  This one is both unlikely and has low cost.


> > I think it's quite important for gcc's long-term health to permit and
> > even encourage academic researchers and students to use it.  And I see
> > plugins as directly supporting that goal.  
> 
> I don't see that.  Why is it that much harder to link in with GCC than doing
> it as a plugin?

It is harder for people who are not used to the myriad details of
building gcc themselves.  Most people these days do not build gcc
themselves, and on gcc-help you will see the plaintive cries of those
who do.  We're talking about grad students focused on their research
here, not people who want to learn the arcana of our build system.

Ian