I've been working on the IR JIT recently, getting more method argument
forms working and reducing the manual specialization I do in the
compiler. More code is working because of that, but it increases the
need for us to get to a baseline from which we can start specializing
and improving the IR.

I attempted to look at heap-scoping today and ran into a couple things
that kept me from making much progress.

1. Pre/post logic for heap scope and frame

Currently the pre/post logic for creating, pushing, and popping
DynamicScope and Frame still lives in the InterpretedIRMethod and
InterpretedIRBlockBody classes, surrounding the actual downcall into
the interpreter. This complicates my job because I either have to
duplicate this logic as-is (ultimately doing scoping, framing, and
backtrace for all IR JIT bodies), or try to do the same ugly
inspection of the scope when defining the method to know if I can omit
it.

I know several flags were also added to IRScope to aid this
inspection, but it now feels like the wrong approach.

I believe we need to move more into explicit call protocols
(instructions to push scope/frame/binding, etc) in the IR, so I can
simply emit the right instructions. I have been unable to find any
method that compiles with explicit call protocols so far.

In pursuit of that baseline, I may just duplicate the same implicit
call protocol, so we can at least get closures and heap-scope-aware
methods working from IR JIT.

2. RuntimeHelperCall and related methods

This logic is used for handling non-local break and return.
Unfortunately it uses rather complicated logic that depends on having
the original IRScope around. Encoding all the necessary information
into the jitted output started to look pretty hairy, so I passed on it
for now.

The three methods this instructions calls should probably be stood up
as their own operations.

...

I can continue duplicating the interpreter's behavior in the jitted
output, so I'm not stuck yet. This won't give us very good
performance, but it will get more code running. IR JIT performance is
going to be heavily dependent on how well we're able to specialize
arity, binding use, and so on...within the IR, before passing down to
the JIT.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to