What is wrong with the JIT

fail.p6

class C::C { };
EVAL 'sub foo() { return C::C.new(a => 1, b => 2) }; foo()' for ^500

jit-failures.txt

What is currently going wrong with the JIT?

First of all, we have the mystery of the cleared jit_entry_label.
This one applies to master. It should be debuggable easily enough.

It manifests as a failed lookup of a dynamic (contextual) variable, in the compiler.
So that is the first problem here; this is a 'deep' problem.
Attached file demonstrates it. What happens is that the frame that defines the $*IN_RETURN variable is compiled after some 105 times of running it.
Then for the first 5 lookups or so, everything is fine. The 6th lookup in the JIT compiled frame, the jit_entry_label is NULL, and so the variable cannot be found.
This is very confusing because within a call chain the JIT entry label should never be NULL; that is, unless the code has reverted to the non-JIT case.
I cannot recall finding evidence of that.... but I should check again.

The second problem is that of even-moar-jit.
Roughly speaking, too many pieces are compiling in too many different ways for me to get a useful idea of what works and what doesn't.
I should probably try to remove templates temporarily so as to check which pieces do and which do not work.
I should also, but I dread doing it, refactor the tiler to
a): linearize it's output, so that compilation is no longer a tree-walk but a list-traversal
b): make register allocation offline, so that it's results can be logged and validated and understood
c): handle both values and parameter args, i.e. in acquiring values
d): generates the minimum-cost table correctly to take into account the 'implied costs' of certain rules. 
(E.g. (load reg) is not cheaper than (load (addr reg)) when they can co-occur, because they can only co-occur when the reg is (addr) anyway. )

So that is a very large amount of work, and what makes it even more difficult is that each part must be correct to start with.