This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
GCC infrastructure and non-GPLed optimizers
- From: "S. Bosscher" <S dot Bosscher at student dot tudelft dot nl>
- To: "'gcc at gcc dot gnu dot org'" <gcc at gcc dot gnu dot org>
- Date: Tue, 20 May 2003 12:06:31 +0200
- Subject: GCC infrastructure and non-GPLed optimizers
Hi,
Yesterday in the discussion about Geoff's "intermodule optimisation patch"
one of the reasons mentioned against the intermodule approach proposed by
Chris Lattner was that "(it) permits people to write non-GPLed optimisers
and code generators and still use GCC's parsers."
(http://gcc.gnu.org/ml/gcc-patches/2003-05/msg01679.html)
The optimization framework proposed by Chris is very similar to the
intermodule framework proposed by many papers, and in fact similar to what
existing compilers, like ORC/Open64, do with some success. So if this
argument holds, then GCC could never have such a framework for intermodule
optimizers.
In a way, the argument blocks the development of GCC itself. Maybe it
should be reconsidered.
So the question is: How relevant do you all think this argument still is
today, considering the facts that:
- Like Chris said, there already are backends
available that write out enough information
(XML, C backends) for a separate non-GPLed
compiler with its own optimizers and backends.
- It does not look very difficult to modify the
tree dumpers in the tree-ssa branch to dump
tree-optimized, compilable C/C++ source code.
So anyone who would want to use GCC's parsers in combination with non-GPLed
optimizers/backends can already do so with only a few modifications. Then
the argument seems to be quite irrelevant.
Thoughts?
Greetz
Steven
PS. Wasn't this argument also used in the past to block making the backend
library a shared library?