Re: Progress on GCC plugins ?

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

Andrew Haley <aph@redhat.com> writes:

> Ian Lance Taylor writes:
>  > Andrew Haley <aph@redhat.com> writes:
>  > 
>  > >  > 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.
>  > 
>  > As we've discussed previously, we are already seeing that without
>  > plugins: GCCfss.  Sun took gcc's frontend and attached it to their
>  > proprietary backend.  So in my view introducing plugins will not make
>  > a substantive difference here.
> 
> Well, yeah, but no-one ever said it wouldn't be possible without
> plugins.

I'm sorry, I've lost the sense of the argument here.  I thought you
were arguing that plugins would make this more likely.  I'm saying
that it's already happening, and that it's not noticeably easier with
plugins.  So can you repeat your point?


>  > >  > 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.
>  > 
>  > But as you know, most gcc ports are never contributed anyhow.
> 
> Sure, but they are still free software: if the compiler gets
> distributed, so does its source code.  Of couse, assigning copyright
> to FSF is nice, but freedom is much more important.

If I follow this, it seems that you are saying that if we have
plugins, some people will choose to use them to get a gcc frontend for
a proprietary compiler rather than doing a gcc port.  I'm sorry, I
don't buy this at all.  Again, people can already do this, and adding
plugins does not make it substantially easier.


>  > Ports that people hire Red Hat to do are contributed, but I can
>  > easily count six gcc ports I've seen myself that were never
>  > contributed. 
> 
>  > So again I don't see a substantive difference here.
> 
> I guess it depends on what you mean by "substantive".  As I said, I
> suspect that if it were easier to decouple the gcc front-end from the
> back-end and to maintain the resulting compiler, there would be fewer
> free compilers.  And no, neither of us can prove it without doing the
> experiment.  I insist, however, that when it comes to a change that
> potentially reduces freedom, the burden of proof -- or at least of
> evidence -- is on those wanting to make the change.

I'm very sorry to hear you take that position.  I think you are
letting an unlikely fear sacrifice a clear benefit.

I have a different fear: that gcc will become increasing irrelevant,
as more and more new programmers learn to work on alternative free
compilers instead.  That is neutral with regard to freedom, but it
will tend to lose the many years of experience which have been put
into gcc.  In my view, if we can't even get ourselves together to
permit something as simple as plugins with an unstable API, then we
deserve to lose.

Ian