On Sun, Jan 26, 2014 at 12:28 AM, Charles Oliver Nutter <head...@headius.com > wrote:
> 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. > I would like to take this a step further (or at least entertain) that pushFrame is fine but having instrs for each element of frame we care about would be better. subbu addresses the whole frame/scope with AddCallProtocolInstructions but I am hoping we can reentertain the idea of spaghetti stacks for things like visibility and only push/pop where it is needed and to omit it as much as possible. For interp I would like these instrs to be grouped so that they can easily be omitted (possibly a BB for this setup). > 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 > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com
