Ok, after some discussion on IRC, here's next steps: * I will add the AddCallProtocolInstructions pass to pre-JIT passes by default and implement the bits needed. A quick experiment shows this doing push/pop of frame and scope with appropriate exception-finally logic, so I just need to fill in the blanks. * Going forward, we will start to lift frame knowledge to IR level, so that we can avoid standing up an entire frame if only one field is needed.
With this in mind I should be able to proceed with JIT work without wrapping every method body in full framing and scoping. - Charlie On Mon, Jan 27, 2014 at 4:44 PM, Thomas E Enebo <tom.en...@gmail.com> wrote: > > > > 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 --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
