Ian Lance Taylor wrote:
Kirill Kononenko <kirill.konone...@gmail.com> writes:
There have been mentioned a couple of ideas indeed. But I would not
like to spend a lot of my precious time on telling my thoughts and
suggestions, if the topic is already decided elsewhere. So I basically
want asking question which exactly JITing support GCC needs, that I
don't spend my time in the rubbish bin. So no productivity of my part
is lost.
In other words, if your goal is to let us know that we can use libJIT,
then: mission accomplished. If your goal is to include libJIT in the
gcc code base, then you need to 1) identify a gcc project which needs a
JIT, 2) convince people to work on it, 3) convince them that libJIT is
the right solution, 4) convince the gcc maintainers to accept the
project and libJIT into gcc mainline. No step may be omitted.
I believe that Kiril mentioned in a separate post the equation
(mcs | csc | cscc) & gcc & libJIT == LLVM ?
I tend to believe that Kiril dreams of building a CLI/.NET
infrastructure and VM which uses all the powerful optimisations of GCC.
For reference to Kiril: do you know that there exist some branches of
GCC (I believe it was contributed by STMicro guys) which are able to
1. Parse (as a front-end) the CLI bytecode and generate the Gimple IR
from it
2. Parse C# (as a front-end) and generate the Gimple IR from it
3. Provide a backend which spills CLI bytecode from Gimple IR (without
using the backend infrastructure of GCC, but "replacing" it).
Maybe these branches could satisfy some of Kiril dreams (which I still
did not understood exactly).
Perhaps Kiril is dreaming of a compile server built around GCC; some
people are experimenting that in their branch.
However, as far as I know, nobody uses libJIT inside GCC, and nobody is
working to incorporate it inside GCC.
Maybe what Kiril is dreaming about is also:
having a compiler server built around GCC.
replacing the use of libJIT inside DotGNU by a library which would
interact with that GCC server, incrementally replacing the CLI bytecode
by their Gimple representation, invoke the various GCC optimisations, etc...
All this is very ambitious.
Maybe Kiril equation is becoming
(mcs | csc | cscc) & gcc & gcc-server & CLItoGimple > LLVM | DotGNU
But I still don't understand what Kiril is dreaming of. It has
apparently no much in common with libJIT, except perhaps at most keeping
libJIT API but rewriting it entirely to interact with a future GCC
server. Perhaps hacking DotGNU to spill Gimple into GCC would be easier.
At last, I am not sure that any kind of JIT compiler would want to use
expansive optimisations as those provided by GCC. JIT & AOT [ahead of
time, like GCC usually works] compilation are really different goals,
with different trade-offs. A JIT wants to translate code quickly into
machine code. An AOT compiler like GCC wants to generate very efficient
code, even while taking a lot of time for that generation.
Maybe a more reasonable project for Kiril would be to enhance & merge
the existing branches for CLI of GCC and the GCC server branch to have
them interact with DotGNU by providing a mode where expansive
compilation is done by GCC. But I am not entirely convinced that GCC is
the good vehicule for that. A lot of stuff inside GCC is really designed
for AOT!
Of course, I don't understand all the details involved. I don't know
much about the various branches I mention in this email.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
