Diego Novillo wrote:
Sebastian Pop wrote on 06/12/06 12:40:
This page has no discussion about a CIL backend.
Note that I never said 'CIL'. I specifically said 'bytecode
representation'. The work being done for LTO will have some points in
common with an effort to build a CIL backend.
The document in which Mark has announced the LTO briefly mentions
that CIL was not retained for dumping the IR, without giving an
explicit reason, so I think that we need a clear position from the
FSF whether such a backend is accepted to be part of GCC.
Yes, that's true. If anyone is interested in contributing a CIL
backend, the FSF would have to approve it. That's not a decision we can
make in this list.
It looks like you don't assume such an approval as granted... may I ask
you why?
To avoid misunderstandings, I want to make clear that the intent of my
post is to propose a CIL back-end, not to suggest CIL as a bytecode
internal representation for link-time optimizations, nor to use CIL to
bump GCC internal representation and to circumvent GPL restrictions.
(Of course, if there are points in common between a CIL back-end and
efforts to build a bytecode representation, it may interesting to share
the infrastructure, or parts of it).
What I need is to produce highly optimized CIL from plain C code,
nothing more, nothing less.
In this sense, such a CIL back-end looks to me not much different from
Java back-end that, to the best of my knowledge, is already included in gjc.
Roberto
