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]

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?


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