This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Progress on GCC plugins ?


Ian Lance Taylor writes:
 > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
 > 
 > > > I don't believe this is a strong argument.  My contention is,
 > > > and has always been, that GCC is _already_ trivial to integrate
 > > > into a proprietary compiler.  There is at least one compiler I
 > > > know that does this.
 > > 

 > > I believe that any such compiler would violate the GPL.  But I
 > > also believe it's not in the best interest of the FSF to litigate
 > > that matter if the linkage between the compiler is anything other
 > > than linked in a single executable.  Therefore, I think it's
 > > important for us to make it as technically hard as possible for
 > > people to do such a linkage by readin and writing tree or
 > > communicating as different libraries or DLLs.  I'm very much
 > > against any sort of "plug in" precisely for this reason.
 > 
 > 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.

 > 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.

 > 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.

Andrew.

-- 
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK
Registered in England and Wales No. 3798903


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]