I have been criticized for inserting a mail from a public mail list into this mail list. My position is that if a guy contradicts himself in two different public mail lists, it is a reason to point to this. Public mail list is a 'public' mail list. It is a source of reference, for books for example even. It is very different from private correspondence, citing which is just disgusting when done intentionally.
Thanks, Kirill 2009/4/3 Basile STARYNKEVITCH <bas...@starynkevitch.net>: > 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} *** > >
