> However, I see several interesting issues raised here: > > the first is to [re-]use GCC for just in time compilation, for instance to > JIT-compile CLI or JVM bytecode into machine code, or even C or some > specialized gimple-like representation into machine code, or CLISP into > machine code, all this using most of existing code in GCC (certainly the > middle-end and a back-end). This might be doable, is certainly interesting > (I heard even that some major GCC contributor[s] wanted that to happen), but > remains difficult (because GCC was not designed for that). Note that libjit > per se is not useful in that case, but GCC would be made as a server (or a > library) which happens to deliver some of libjit or LLVM functionalities > (the ability to generate code). > > 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. > > I still don't understand what Kiril is thinking of exactly. In contrast to > Andrew, I don't believe it is an April Fool's joke, but perhaps a language > issue: both Kiril & me Basile are not native English speakers, and we may > have difficulties in finding the right words & express ourself fluently in > English. If it is the case please forgive us (or just try to interact on a > french or russian mailing list!). > Thanks, Kirill
