2009/4/1 Basile STARYNKEVITCH <bas...@starynkevitch.net>: >>> >>> 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). >
Thank you a lot, Basile, for your support. Thanks, Kirill
