>> 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, that's true. But it doesn't in any sense require libjit to be integrated > with gcc to achieve this: the jit could just be called as an external library. > >> 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. > > For what it's worth, I didn't really think this is April Fool's joke; I was
Everyone who read that, might have thought you really meant that. > just trying to provoke Kirill into explaining his purpose. I seem to have > failed to do that. > My explanations seem to have also failed to explain you. Unfortunately, one really needs have some back group with both Just-In-Time compilers,Virtual Machines, and Common Intermediate Language to understand this area. I understand that it is not your area of expertise, so it is not an issue for me. Thanks, Kirill
