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 > > ... > 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. >
Agreed. Look in passes/AddCallProtocolInstructions.java Right now, it has to be explicitly enabled by adding to the list of default passes run. jruby -X+CIR -Xir.passes=OptimizeTempVarsPass,LocalOptimizationPass,AddCallProtocolInstructions,LinearizeCFG foo.rb You can check the logic for these instructions in Interpreter.java (PUSH/POP FRAME/BINDING operations). Caveats: 1. I had tested this about a year back and had ironed out bugs, but I haven't really run rubyspecs since then with all these passes enabled to see if there are bugs, but these bug fixes should be independent of you being able to use them. 2. This still leaves one last bit of pre/post logic that hasn't made it into instructions (that I discovered couple months back), and that is push/pop backtraces. It is simple to add. But for now, if you simply ignored backtraces for now (and wait or add push/pop backtrace instructions to IR), there is zero pre/post logic that you would need to add to IR JIT while compiling methods. 3. These instructions are only added to Method scopes, not block scopes because block scopes are significantly more hairy with all kinds of argument lining up and massaging that needs to get done. Tom, you, and I have talked about converting these to explicit instructions at different points, but this will require more thinking and working through because JRuby runtime code paths also call blocks directly which complicates the picture a bit. But, this can be solved if we sit down, brainstorm and work through it. 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. > The primary motivation for current design of non-local break/return handling is to purge jruby's core libraries (Enumerable, Enumerator, Proc, etc.) from all traces of needing to handle breaks and non-local returns. I think that goal has been accomplished since the interpreter's break/non-local return handling is completely localized to the ir implementation without leaking into the core libraries. With an eye towards IR JIT, I cleaned up the previous version of break/non-local return handling in the interpreter and embedded all logic into three runtime-helper calls (which are generated as a RuntimeHelperInstr instruction in IR). But, looks like I did not finish up the last bit that was required -- that is removing IRScope as an argument to RuntimeHelperInstr.callHelper(...) which is what you are blocked by. At first glance, it appears that IRScope that is used there should be retrievable by looking at currDynScope.getStaticScope().getIRScope() where you cast getStaticScope() into an IRStaticScope. I haven't tried this, but maybe you can give this a shot in Interpreter.java / RuntimeHelperInstr.java or in JIT directly to see if that works. If it does, then this should solve this blocker for you. I am busy rest of the day today, but if you dont get to it before me, I'll give it a shot tomorrow. Exciting to see IR JIT filling up and being able to identify blockers and necessary IR tweaks to streamline it. I think we'll need some more iterating over the current IR design to make it smooth both for interpreter and the JIT, but I think we are getting quite close. Subbu.
