Forwarding this to the general compiler mailing list. It's about MoarVM, spesh and the JIT. Long story short, the MoarVM JIT relies subtly on the earlier code-generation of specialized (interpreted) code, which will in all likelihood never be executed. But because the JIT relies on it - or rather features like deoptimization rely on it, and the JIT relies on those - we can't remove this codegen simply. Any thoughts are quite welcome.
---------- Forwarded message ---------- From: Bart Wiegmans <bartwiegm...@gmail.com> Date: 2015-01-07 0:38 GMT+01:00 Subject: Eliminating the spesh codegen for jittable frames To: timona...@perpetuum-immobile.de, Jonathan Worthington <jn...@jnthn.net> Hi, I'm going to repeat myself just in case you don't backlog, or in case I was vague on IRC. Correct operation of the JIT - at runtime - relies currently on spesh codegen, and that is not very simple to change. Specifically, we rely on the offsets calculdated during spesh codegen to determine what to do in at least two cases: deoptimization and OSR. OSR looks at the deopts table in the function 'get_osr_deopt_finalize_index'', (src/spesh/osr.c:19) which - I think - is written during spesh codegen (src/spesh/codegen.c:105). But maybe that isn't true, because that index is calculdated on a logging frame when calling MVM_spesh_osr_finalize, triggered by sp_osrfinalize. So OSR is probably OK, since the JIT uses the deopt idx and the label rather than the bytecode offset. Deoptimization is almost certainly not ok. The JIT relies directly on the bytecode targets calculated during codegen via the function MVM_spesh_deopt_one_direct (src/spesc/deopt.c:199). These addresses, deopt_offset and deopt_target, are bytecode offsets respectively. I think the deopt_target is set during spesh graph generation (src/spesh/graph.c:86). deopt_offset is certainly set during codegen though: src/spesh/codegen.c:216-221). Unfortunately we *do* rely on this value for uninlining, see src/spesh/deopt.c:20, namely to determine in which inlined frame we are. In theory we do have this value for the JIT, in the inlines array, which is just an array of start and end labels. These labels correspond to bytecode addresses in the MVMJitCode labels array (an array of void*), which means that using the jit_entry_label you can actually figure out in which inline you are, thereby not needing the codegen-ed offset anymore. So... there you go, I guess. Regards, Bart
