Kirill Kononenko wrote (citing me Basile)
The second issue (which perhaps Kirill did not thought of) would be to
accelerate some internal optimisations of GCC by using JIT-code generation
techniques within the compiler itself. There are several occasions within
GCC where complex internal processing happens, and one could imagine to
"partially evaluate" them (w.r.t. to the compiled source program) by
generating some code specifically tuned to that processing. BTW, the MELT
branch was designed with such stuff in mind, and indeed can generate some
code (currently, it generates C code, run the host compiler on it, dlopen
it, and use it; in principle I could have used libjit instead of forking a
compilation process from inside cc1).
Yes, this is exactly one kind of opportunity I see here. Basile is
absolutely correct here.
The standard answer to that would be : find an interesting use case (of
JIT compilation inside GCC, eg inside some complex optimisation pass)
and implement it in your branch.
I invested too much effort in C code generation in MELT, so I won't
switch quickly to libjit, even if it could help a lot.
However, once the plugins machinery comes into the trunk, nothing
prevent Kiril or others to experiment a plugin which uses libjit
internally. And you (Kiril or others) could even start a branch right
now (provided you did comply with the legal requirements of
http://gcc.gnu.org/contribute.html ie the FSF copyright transfer).
--
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} ***
