Re: GCC + libJIT instead of LLVM

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Ian Lance Taylor wrote:
> Kirill Kononenko <kirill.kononenko@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} ***